The flaw is not in your theme, your plugin, or your checkout. It is in the language your whole site runs on.
On October 21, 2026, the PHP project released an emergency update for two vulnerabilities that let an unauthenticated attacker execute code on a web server. Both are rated 9.2 out of 10. The affected software is not a plugin you can disable or a theme you can swap. It is PHP itself — the runtime underneath WordPress, Joomla, Drupal, Magento, and roughly 70 percent of the web.
By the time the patch landed, exploitation had already been observed in the wild.
This is the one where reading the whole post matters, because the correct action depends on something most site owners have never had to think about: who manages your PHP.
What actually happened
The two flaws are tracked as CVE-2026-109618 and CVE-2026-109619, collectively nicknamed "php2shell." The PHP security team scored both 9.2 under CVSS v4.0.
They share a root cause, and it is an uncomfortable one. PHP allocates memory to serve each request, then frees it when the request finishes. When a request dies partway through — most reliably by running out of memory — PHP's error handling can leave internal state pointing at memory that is half-built or already released. A later request handled by the same worker can then be handed that stale memory and treat it as valid.
Two consequences follow. An attacker can corrupt that memory and execute their own code. Or, more quietly, they can read it. Wiz Research, one of the teams credited with the discovery, notes that disclosed memory "may contain passwords, authentication tokens, API keys and certificates belonging to other requests or the server itself."
That second half deserves a moment. Most breach stories are about data being taken from a database. This one is about secrets being read out of the server's own working memory, from other people's requests — including requests that authenticated successfully.
The fixes shipped in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Anything from PHP 5.4 onward is affected by at least one of the two flaws.
Why this one is different from the usual plugin scare
Most website security news you read is about a plugin or a theme, and the answer is always the same: update the plugin. That answer does not work here.
As Cloudflare put it in their own advisory, these flaws are in the PHP runtime, so "updating website code or a plugin(s) alone does not fix these vulnerabilities." A site with every plugin current and every theme patched is still exposed if the PHP underneath is old.
Wiz was blunt about the scale of it. Their writeup calls these findings "among the most severe vulnerabilities discovered in PHP, and arguably in software history," and draws the comparison to Log4Shell — the 2021 Java logging flaw that took organizations months to fully root out because nobody had a complete list of everywhere the library ran.
There is a second reason this one matters beyond its severity. Wiz states the underlying flaws "had been present for decades," but that demonstrating exploitability "required an exceptionally complex chain of steps, at the edge of what human researchers could practically achieve." Frontier AI models collapsed that barrier. A flaw that sat unexploited for years became a working exploit.
That is a meaningful shift, and it will not be the last time we see it. The gap between "theoretically exploitable" and "practically exploited" just got shorter for a whole class of old bugs.
Is your site affected? The honest answer depends on one question
This is where most coverage gets sloppy, so here is the precise version, straight from the PHP advisory.
The demonstrated, application-independent attack — the one where an unauthenticated request triggers code execution before any of your application code even runs — was proven against Apache with mod_php. That configuration runs PHP inside the web server process itself.
PHP-FPM, the setup most modern hosts use, behaves differently. When a request fails at startup, FPM terminates that worker and replaces it, which blocks the application-independent path. The advisory for CVE-2026-109618 states plainly that "no complete FPM exploit has been demonstrated for this SAPI." For CVE-2026-109619, the validated FPM path depends on a suitable operation in the application itself.
So the risk is real everywhere but concentrated: oldest and most severe on mod_php, conditional on FPM.
Which means the single most useful thing you can do today is find out which one you are running. You do not need to understand the difference to answer it. You need to ask.
What to do today
If your host manages PHP for you — which covers most shops on shared hosting — this is a support ticket, not a server job.
Ask your host three things in one message:
- Which PHP version is my site running, and has it been updated to 8.5.12, 8.4.27, 8.3.36, or 8.2.35?
- Are you running PHP as mod_php, PHP-FPM, or LiteSpeed?
- If my PHP is 8.1 or older, what is the upgrade path and when?
That last question matters more than it sounds. PHP 8.1 and older will not receive an upstream fix at all — the project has ended support for them. Some distributions and long-term-support vendors backport patches, and PHP published minimal source backports for 7.4, 8.0, and 8.1 for people who build from source. But if your host is sitting on PHP 7.4 because something in your stack breaks on newer versions, you have a decision to make this week, not next quarter. PHP 8.2 also reaches end of life on December 31, 2026, so 8.2 is a waypoint, not a destination.
If you run your own server, update PHP today and restart every PHP worker. The advisory is explicit that updating is the only complete mitigation. Restarting matters: an updated binary with old workers still running is not fixed.
If you use Cloudflare, you already have a safety net — and this time the free tier is genuinely covered.
This is worth stating clearly because it is often not true. Cloudflare deployed WAF rules against these exact flaws from 03:02 UTC on October 21, roughly nine hours ahead of public disclosure, and their post says the protections are "available and deployed automatically on all plans with WAF deployed, including Free users." No action needed on your part.
Keep it on. But read the next line carefully: Cloudflare themselves say to patch anyway. A WAF is a second layer, not a substitute. Attackers were already observed mutating their payloads to try to slip past the rules within hours of deployment.
If you cannot update immediately
The PHP advisory offers interim measures and is honest that all of them are partial. Two are practical enough for a site owner to pass along:
Turn off session upload progress. Setting session.upload_progress.enabled=0 closes the confirmed session-based path for the stale-memory flaw. It must be set in php.ini or the pool configuration — not at runtime, and not in .user.ini, which are both applied too late to help. Every worker has to restart afterward.
Keep request sizes small and boring. For the out-of-memory flaw, a low post_max_size — 8 MB if you do not take uploads, 32 MB if you do — shrinks the room an attacker has to work with. If your site has no file upload form at all, blocking multipart requests at the edge removes a large part of the attack surface outright. If you are unsure whether your site has an upload form, that alone is worth checking.
One warning that sounds technical but matters: do not use RLIMIT_AS or RLIMIT_DATA as a memory guard. Both make memory allocation fail at the limit, which is exactly the condition that triggers the vulnerable code path. A container or cgroup limit is the safer boundary.
Separately: if you run your own nginx
A week earlier, on October 14, 2026, nginx released 1.30.6 (stable) and 1.31.7 (mainline) fixing five vulnerabilities. Three of them are memory-safety bugs in the worker process that F5 scores 9.2 — a heap overflow in the alias directive when combined with rewrite, another heap overflow in map with regex captures, and a use-after-free when asynchronous file I/O meets server-side includes.
nginx.org rates all five as medium, and that is not a contradiction. Each one requires a specific, non-default configuration to be reachable. If your config does not use alias with rewrite, does not put regex map captures into root or a log format, and does not combine aio with SSI, your practical risk before you upgrade is low.
This part is genuinely not relevant to a shop on shared hosting. It is relevant if you run your own VPS or a dedicated server, and it is worth an hour of your host's or developer's time. No in-the-wild exploitation had been reported for these five at the time of writing.
Key numbers
- 9.2 — CVSS v4.0 score for both PHP flaws
- 70% — share of websites running PHP, per W3Techs
- 5.4 onward — every PHP version affected by at least one flaw
- 8.5.12, 8.4.27, 8.3.36, 8.2.35 — the only fully patched releases
- 22.6 million — internet-exposed instances Palo Alto's Cortex Xpanse telemetry flagged as potentially vulnerable at the time of its brief
- 03:02 UTC, October 21 — Cloudflare WAF coverage live, including free plans
- December 31, 2026 — PHP 8.2 end of life
The takeaway
This is not a plugin problem you can solve by clicking update in a dashboard, and it is not a theoretical advisory you can file for later. It is a flaw in the layer everything else sits on, it has been demonstrated end to end against real content management systems, and exploitation attempts started within hours of disclosure.
The good news is that for most small businesses the fix is one conversation with your host, and if you are behind Cloudflare you have real same-day coverage while that conversation happens. The thing that turns a bad week into a bad year is assuming someone else already handled it.
Find out what PHP version your site is running. Ask today.
Not sure where your site stands? Run a free security scan — 40+ automated checks on the public signals that matter, instant results, no commitment.