Three things set PHP2Shell apart from the usual critical CVE.
First, it is not in your application. You can patch WordPress, Drupal and every plugin you run and still be exposed, because the flaw is in the engine executing them. That also makes it hard to inventory. PHP turns up in container base images, in control panels, and in appliances that bundle it. The UK's NCSC guidance points readers to an inventory of products with a PHP dependency compiled by its Dutch counterpart.
Second, it can fire before your code does. Datadog's reproduction triggered the out-of-memory corruption with a single unauthenticated POST that never reached the target application's code. Your login page, your authorisation checks and your application-layer logging all sit downstream of the bug. "No authentication required" undersells it. The vulnerable code runs before authentication gets a say.
Third, the mitigations are partial. PHP says updating is the only complete fix. For servers that cannot be updated yet, it published interim settings, and they reduce exposure to some attack paths without closing the others.
Then there is the clock. Details leaked on 20 October, PHP published an advance notice that evening, and the fix shipped at about 14:00 UTC on 21 October. SecurityWeek reports that several companies saw exploitation attempts before the patches landed, and Cloudflare had WAF protections in place nine hours before public disclosure. SC Media reports that CISA advised organisations to patch immediately.
Wiz argues that AI has changed the economics here, lowering the barrier to turning a decades-old flaw into a working exploit. That is Wiz's own claim, and we cannot verify it independently. It does not change what you have to do, but it is a fair reason to expect the gap between a bug existing and a bug being usable to keep shrinking.
The Identity Angle: What an Attacker Gets After the Shell
Code execution as the web worker account is where the identity story starts, not where it ends.
A PHP worker is rarely empty-handed. Its environment and configuration files often hold database credentials, API keys for payment, email and cloud services, and the signing or session secrets the application relies on. In a container, it may also carry a cloud role or service account token. SecurityWeek notes the flaws can be used to read sensitive process memory, which may contain credentials and API keys, and Wiz demonstrated unauthenticated disclosure of PHP worker memory as well as code execution.
So the useful question after "are we patched?" is "what could that worker reach?" Every credential it held is a credential an attacker may now hold, and each opens a different door: the database, the cloud account, a third-party API, the administrator session of the application itself. The blast radius was set long before the vulnerability appeared, by how much that workload identity was trusted.
That is the part we would put in front of a CISO. Patching closes the engine bug. It does not revoke secrets that may already have been read.
Key Takeaways
- PHP2Shell is a pair of critical flaws in the PHP engine (CVE-2026-109618 and CVE-2026-109619, both 9.2 on CVSS 4.0) that allow unauthenticated remote code execution on servers handling web requests.
- The bug is in the runtime, so patching your CMS is not enough. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
- The vulnerable code can run before application authentication, so login controls do not help.
- Exploitation attempts were seen before patches landed. Treat unpatched internet-facing servers as potentially compromised.
- Patching does not revoke secrets. Rotate what the web tier could read, and cut what workloads can reach.
Source Credits: PHP security advisories (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp), Wiz Research, BleepingComputer, SecurityWeek, SANS ISC, Datadog Security Labs, UK NCSC, SC Media
