PHP2Shell, explained without the panic
Two bugs in the PHP engine let an unauthenticated attacker run code on a web server. Here is what is actually affected, what is not, and what the fix is.
In one paragraph. On 21 October 2026, PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical memory-safety flaws, CVE-2026-109618 and CVE-2026-109619, rated 9.2. They sit in how PHP handles memory when a request fails or a fatal error interrupts it, so the flaw is in the interpreter, not in any application. Every PHP installation serving web requests is affected, back to at least PHP 5.4. On Apache with mod_php, one unauthenticated request is enough to execute code before your application even runs. Check your version →
What the two flaws actually are
CVE-2026-109618 — corruption when PHP runs out of memory
PHP aborts an out-of-memory condition with a non-local jump, which unwinds the C stack without running the cleanup that the interrupted code owed. If that happens while PHP is still building the $_POST or $_FILES arrays — during request startup, before your script runs — it can leave a half-initialised entry behind. The request teardown then treats the leftover bytes as a valid structure and calls through them.
An attacker forces that state by making a request that exhausts memory while staying inside the apparent request limits: a multipart body with no usable Content-Length, or hundreds of empty file-upload parts with nested field names, each of which expands into a dozen internal allocations.
CVE-2026-109619 — stale state carried into the next request
PHP workers are long-lived and hold global state that temporarily points at the current request's memory. A fatal error can skip the reset, so the pointer survives after the memory is freed. A later request on the same worker can follow it. The most-cited instance: the session upload-progress feature runs before normal module initialisation, so a second request can be made to reuse a dangling session structure.
This one also has a disclosure path with no code execution at all: a crafted upload can make PHP emit a PHPSESSID cookie containing live worker memory — the kind of bug that leaks database passwords, API keys and session tokens belonging to other requests.
What is exposed
| Setup | Is one request enough? |
|---|---|
Apache with mod_php | Yes. Demonstrated over HTTP with default limits, before any application code runs. Highest risk. |
| PHP-FPM (nginx and most modern stacks) | Usually needs an application-level operation such as a session start or unserialise to complete the chain. |
| FrankenPHP | Likely, by source analysis — it behaves like mod_php on shutdown. |
| LiteSpeed (LSAPI) | Application-specific exploits likely; not publicly validated. |
php-cgi | Affected. No complete public exploit. |
Because the flaw is in the engine, the application does not matter. Researchers demonstrated unauthenticated code execution against stock WordPress, Drupal and Joomla containers, and against Magento, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCS installations.
Is WordPress affected?
WordPress is not the vulnerability, and updating WordPress does not fix it. WordPress runs on PHP; if the PHP underneath is old, the site is exposed regardless of how current the CMS, theme or plugins are. This distinction caused a lot of wasted time in the first 24 hours, because “update your plugins” is the reflex answer to any WordPress security warning.
Is it being exploited?
Yes, and earlier than the public timeline suggests.
- Amazon Threat Intelligence found an exploitation attempt against its honeypot network dated 17 October 2026 — four days before disclosure — from an address on a commercial anonymisation network. It reported PHP2Shell was “being broadly exploited in the wild”.
- Public proofs of concept appeared from about 02:00 UTC on 21 October, roughly twelve hours before the coordinated release.
- Cloudflare had managed WAF rules live from 03:02 UTC, about nine hours before disclosure, and observed attackers mutating payloads to evade them.
- CISA said it had not observed exploitation at the time of its alert; that reflects a different vantage point, not a contradiction.
What had not been reported publicly at the time of writing was a confirmed mass compromise of named victims. The organisations that went offline — parts of the Dutch and Finnish governments, the BBC, Edinburgh Council, Wikimedia systems — did so as a precaution.
How the patch came about
The underlying code path dates to the PHP 5 era. A 2024 external audit flagged the out-of-memory issue, but no one had proved it exploitable, and the fix stalled on design trade-offs — the PHP Foundation later described that delay as “a structural failure”. In 2026, researchers at Calif, working through OpenAI's Patch the Planet programme and using frontier models, produced working exploits, and Wiz independently found the same class of bug. The CVE identifiers leaked on 20 October, the release was pulled forward a day, and one distributor published fixed images about six hours before the coordinated release — giving attackers a patch diff to study while everyone else was still waiting for packages.
Common questions
Do I need to update WordPress?
Not for this. Update the server's PHP runtime. If you are on shared hosting, that is your host's job — ask them for the version and the restart date in writing.
I updated PHP but I am still worried.
Check whether the workers restarted. A package upgrade replaces files on disk; the processes already running keep the old, vulnerable code loaded. That is the single most common gap. Verification steps →
Does my firewall or CDN protect me?
Partly, and only for traffic that passes through it. If your origin answers on its own IP address, the rules never see the request. Treat WAF coverage as a stopgap and patch.
Is it in the CISA KEV catalog?
Not as of 22 October 2026. That does not measure your risk — KEV is a remediation-deadline list for US federal agencies.
What if I am on PHP 7.4 or 8.1?
There is no official release. Your options are a vendor backport (Ubuntu ESM, Debian ELTS, TuxCare, cPanel, CloudLinux) or an upgrade. Nothing exists for PHP 7.3 and below. Platform detail →
Primary sources
- PHP security advisory, 21 Oct 2026 — php.net
- GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp — github.com/php/php-src
- CISA alert — cisa.gov · NSA statement — nsa.gov
- CERT-EU Advisory 2026-018 — cert.europa.eu · NCSC-UK — ncsc.gov.uk
- Technical write-ups: Calif, Wiz, Datadog Security Labs
- Exploitation and mitigations: AWS, Cloudflare, PHP Foundation
- Product inventory of software embedding PHP — NCSC-NL
Check your own server in 60 seconds
Paste your PHP version and get a verdict plus the command for your platform.
Run the check Read the fix runbook