the short version
- Every PHP release since version 5.4 is affected by at least one of the two CVEs, with severity reaching CVSS 9.2.
- The bugs sit in PHP's core engine, so even a 'Hello World' app on a vulnerable version can be exploited regardless of application code.
- Applying the October 21, 2026 PHP security update is, per the vendor, the only complete remediation.
- Frontier models including Gemini 4 Argon and GPT-5.6 Sol turned a decade-old flaw into a working exploit that was adapted across multiple applications in hours.
PHP2Shell is a single exploit script that Wiz Research built from four memory-safety bugs in core PHP, grouped under CVE-2026-109618 and CVE-2026-109619, and used to execute code without authentication on WordPress, Drupal and Joomla. Every PHP release in the last decade is affected, going back to version 5.4, with severity reaching CVSS 9.2. PHP shipped the fixing patch on October 21, 2026, and Wiz says applying that update is the only complete remediation.
The reach is the point. Wiz describes PHP as the language behind roughly 70% of all websites, including WordPress, Joomla, Drupal and MediaWiki, the software that runs Wikipedia. Because the flaws live in the engine rather than in any one application, a website whose own code is secure can still be exploited. The demonstrations against three content management systems are illustrative, not required: exploitation does not depend on an application bug.
What php2shell lets an attacker do
Two distinct impacts were demonstrated. The first is remote disclosure of PHP worker memory: an unauthenticated attacker can read an attacker-sized region of live process memory that may contain passwords, authentication tokens, API keys and certificates belonging to other requests or the server itself. The second is unauthenticated remote code execution. Wiz combined the memory-disclosure primitive with a corruption primitive to remove address uncertainty and get code execution end to end.
- CVE-2026-109618 was used for application-agnostic remote memory disclosure and for pre-authentication RCE on WordPress, Drupal and Joomla.
- CVE-2026-109619 was used to corrupt shared PHP state and achieve pre-authentication RCE on Drupal and WordPress.
- Wiz tested against the latest container images at the time: wordpress:latest, drupal:latest and joomla:latest.
Which PHP versions and worker setups are exposed
Wiz states that nearly every PHP version is affected by at least one issue, including releases dating back to PHP 5.4. All four bugs are memory-safety issues rooted in how PHP handles fatal errors, particularly out-of-memory errors, while processing a request. A fatal allocation failure can tear down the request heap but leave a global pointer published, so a corrupted internal state survives the request. The exploit then depends on a later request handled by the same worker reusing that stale state, which points at persistent-worker deployments; the OPcache bug additionally requires OPcache's shared-memory cache. The sources do not enumerate specific SAPIs by name, so defenders should assume any affected version is at risk until patched.
How the four bugs chain into RCE
Wiz's deep dive describes four exploitable instances of one problematic pattern, and notes other tracked and likely untracked variants fold under the same two CVEs. The common thread is a dangling pointer to the previous request's heap, reused by the next request on the same worker.
- Upload-progress unserializer use-after-free: the Session module decodes session data in a pre-initialization window and stores bookkeeping in BG(unserialize); a fatal allocation failure leaves that global published, giving a cross-request memory-corruption primitive.
- Remote process-memory disclosure: PHP parses RFC1867 multipart requests at startup and can publish a session ID in PS(id); after an out-of-memory abort, a later multipart request URL-encodes reclaimed heap into a PHPSESSID response cookie, and it works even when the app never calls session_start().
- Fatal-error backtrace use-after-free: PHP retains the last fatal error's backtrace in EG(last_fatal_error_backtrace); an out-of-memory error can destroy the heap without undefining it, and a diagnostic early in the next request follows attacker-reclaimed memory (demonstrated as RCE on Drupal).
- OPcache type confusion: during zend_accel_script_persist() PHP advances the process-local CG(map_ptr_last) frontier before publishing the shared frontier; a failure between the two leaves partially persisted objects, and another worker reusing a slot resolves a pointer of the wrong type (used for RCE on WordPress).
How Gemini 4 Argon found a decade-old flaw
Wiz credits frontier models with making this practical. The vulnerable code had been present for more than a decade, and turning it into a working exploit required chaining bugs and accounting for how PHP allocates and reuses memory across requests, which differs by version, configuration and application behavior. Wiz used Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol throughout, singling out Gemini 4 Argon for finding the vulnerability, developing exploits, building detections and validating the patch. The team says models let them develop and adapt working exploits across multiple applications in hours, and frames this as a turning point comparable to 2014's Heartbleed and 2021's Log4Shell.
For over a decade, these critical vulnerabilities remained unaddressed because vulnerability discovery and exploitation were incredibly complex.
Commenters on Hacker News pushed back on the framing. Several noted the flawed code is at least a decade old (one said 20 years) and that no compute costs for discovery or exploitation were disclosed, so the economics claim is hard to check. Others said both bugs may have been reported before, pre-AI; the sources provided here do not confirm that. One commenter also questioned Wiz prominently crediting a product it sells and a model it had early access to.
What to patch and how to watch for exploitation
The patch is the remediation. Wiz worked with the PHP team, Calif and OpenAI on discovery, coordination and patch verification, and with Automattic, Akamai, AWS, Cloudflare, Fastly, Google, Imperva, Microsoft, Vercel and others to prepare out-of-the-box mitigations for organizations that cannot update immediately. Because these issues execute below the application layer, application logs may hold little context, so Wiz lists behavioral signals to watch until systems are patched.
- Unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses.
- Unexpectedly large or malformed PHPSESSID response cookies.
- Unexplained PHP worker churn.
- Apply the PHP security update as the only complete fix; Wiz says the PHP team's patch addresses the issue at its core and eliminates all variants in the patched release.
The two-month disclosure timeline and the leak
The PHP project pre-announced the release on October 20, 2026 under the title 'Upcoming critical PHP security release (CVE-2026-109618 / -109619)', and a Hacker News post the same day was titled '2x PHP RCE CVEs with CVSS 10.0 Incoming' - though Wiz's published figure is CVSS 9.2. Commenters on Hacker News laid out a timeline they attribute to the article: discovery on August 19, 2026, confirmed RCE on Drupal August 20 and WordPress August 21, a report to PHP on August 24, acknowledgment on September 21, and patch plus public disclosure on October 21. Several asked why acknowledgment took a month and how details appeared to leak ahead of disclosure; one speculated a demonstration video exposed enough for other LLM users to rediscover the bug, and another wished downstream distributors had been given time to patch. The sources here do not resolve those questions, and OpenAI's coordination write-up was not retrievable for this note.
Questions this raises
Which PHP versions are vulnerable to PHP2Shell?
Wiz says nearly every PHP version is affected by at least one of the four bugs, including releases back to PHP 5.4. The sources do not name specific SAPIs, so any unpatched affected version should be treated as at risk.
Does a secure WordPress, Drupal or Joomla site still need to patch?
Yes. The flaws live in the PHP engine rather than in application code, so exploitation does not depend on an application bug. Applying the PHP security update released October 21, 2026 is the only complete fix.
How can defenders spot PHP2Shell exploitation before patching?
Wiz lists unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, unexpectedly large or malformed PHPSESSID response cookies, and unexplained PHP worker churn. Application logs may hold little context because the issues execute below the application layer.
Spotted an error? Email samir.s.sengupta@gmail.com and I will correct it and date the change at the top of the note. How these notes are researched, drafted and checked is in the editorial policy.