PHP2Shell: What This Week's PHP Security Alert Means for Your Website
On October 21, the PHP project released emergency updates for two flaws that let an attacker run their own code on a web server without logging in. Both are rated 9.2 out of 10 for severity. By October 24, security researchers had confirmed working attacks against real systems. On October 26, the U.S. cybersecurity agency added both flaws to its list of vulnerabilities known to be exploited in the wild.
PHP is the software that runs most of the web — roughly seven in ten websites, according to W3Techs — and it is what WordPress is built on. If your business site runs on WordPress, this is the week to confirm it has been patched. Here is what happened, how to check your own site in a few minutes, and the habits that make the next one a non-event.
What Actually Happened
The two flaws are CVE-2026-109618 and CVE-2026-109619. One is a memory-handling bug: under the right conditions, a request can interrupt PHP while it is still setting itself up, and the cleanup code then treats leftover data as if it were valid. The other lets some internal request state survive after the request it belonged to has finished, so a later request handled by the same worker can pick up stale data.
Both end in the same place: unauthenticated remote code execution, which means an attacker who can reach the site can make the server run commands of their choosing, with no username or password.
The fixes shipped on October 21 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Every one of those releases exists for this purpose alone.
The PHP project judges the risk highest for servers running mod_php, where an unauthenticated request can trigger the attack before any of your application code runs. PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are all affected too. PHP 8.1 and older no longer receive updates from the PHP project directly, though some hosting vendors and Linux distributions have backported the fix.
Does This Affect My Website?
It depends entirely on how the site is built and who runs the server under it.
Squarespace, Wix, Shopify, Webflow: not affected. These are hosted platforms, not PHP you manage. Ours is on Squarespace for exactly this reason.
WordPress on managed hosting: your host patches PHP. Most do it quickly, but "trusted host" is not the same as "confirmed patched". Ask them.
WordPress on budget shared hosting: same answer, with more variance. Some hosts run old PHP for years because upgrading breaks something.
A VPS, a dedicated server, or a custom PHP application: this is yours to patch. Nobody else is watching it.
If you do not know which of these you are, that is the first thing worth fixing — it is the question every future incident will start with.
How to Check, in About Five Minutes
Find your PHP version. In WordPress, go to Tools → Site Health → Info and open the Server section. It lists the PHP version your site is running.
Compare it with the fixed versions. 8.5.12, 8.4.27, 8.3.36, 8.2.35 or anything newer. An older number means your site is still exposed.
Ask your host in writing: "Which PHP version does my site run, and has it been updated for CVE-2026-109618 and CVE-2026-109619?" A good host answers with a version and a date. A vague answer is an answer too.
Look for signs of use. New administrator accounts you did not create, plugins or themes you do not recognise, unexpected redirects, strange outbound traffic, or a sudden warning in Google Search Console. Any of these deserve a proper look, not a shrug.
On WordPress, check the version the site reports and the version the host says it runs. They are not always the same thing on a shared server, and the host's number is the one that matters.
If You Cannot Update Today
The PHP project published partial mitigations for people who genuinely cannot patch immediately. Be clear about what they are: they close specific attack paths, they do not make a site safe, and the only complete answer is updating.
For the memory-handling flaw: set memory_limit=-1 in a way the application cannot override, such as php_admin_value in the FPM pool or Apache config. Lower post_max_size to 8M if you do not accept uploads, or 32M if you do.
For the stale-state flaw: set session.upload_progress.enabled=0 and restart every worker. On PHP 8.5, also set fatal_error_backtraces=0.
These are server settings, not WordPress settings. If that sentence sounds like someone else's job, it is — and that someone is whoever manages your hosting.
The Habits That Make This a Non-Event Next Time
Know your stack. PHP version, who patches it, and how you would hear about the next one. Write it down somewhere you will look.
Patch on a schedule, not on the news. PHP and operating system updates monthly; WordPress core as it ships; plugins weekly. Test on a staging copy where a surprise is cheap.
Back up, and restore one. An untested backup is a hope, not a recovery plan. Restore an old copy somewhere and confirm it works.
Put a wall in front. A service like Cloudflare or a host-level firewall buys hours, and hours are the difference between a quiet week and a bad one.
Reduce what can be attacked. Delete plugins and themes you do not use, remove administrator accounts nobody needs, and turn off file editing in the WordPress dashboard.
Watch for change. Uptime monitoring plus something that notices new files in the WordPress install catches more than most owners expect.
Have the first hour written down. Who you call, what you check first, how you take the site offline, who writes the message to customers. Deciding that in the moment is how small incidents become expensive ones.
Common Mistakes
Assuming the host handled it without asking for a version and a date.
Believing a security plugin patches PHP. It cannot — PHP is server software sitting under WordPress, not part of it.
Updating every plugin but never PHP. The plugins were never the hole this time.
Backing up but never restoring. You find out whether a backup works on the worst possible day.
Panic-migrating mid-incident. A rushed platform move in the middle of an active exploit trades a known problem for an unknown one.
What We Did This Week
We ran the same check on every site we manage: pulled the PHP version behind each one, compared it against the patched releases, and flagged anything that needed moving. It is a short job when the hosting is known and someone already has access — which is the argument for knowing both before an alert, not during one.
The Bottom Line
This one is serious, it is public, and it is being used. The good news is that the fix is a PHP version update that most hosts can apply in minutes, and many already have. The useful action today is not worry — it is one email to your host asking which PHP version your site runs and whether it is patched, plus a look at your WordPress admin accounts for anything you did not create.
Then fix the conditions that made it alarming: nobody should have to discover their PHP version during an incident.
Checked against the PHP project's own advisory on October 27, 2026. Details move quickly on active vulnerabilities — the PHP security page at php.net is the primary source.
Not Sure Where Your Site Stands?
We can confirm what your site is running, whether it is patched, and what it would take to keep it that way. Start with our website development services, or contact us and we will look at your setup before the next alert lands.
