PHP2Shell: Two Critical PHP Core Flaws Enable Remote Code Execution

On October 21, 2026, the PHP team shipped emergency updates for “PHP2Shell”, two critical vulnerabilities buried in the PHP engine itself. They let an unauthenticated attacker execute code remotely on a web server, before any application code even runs. Discovered by Wiz Research with the help of AI models, they affect nearly every PHP version released over the past decade. Amazon observed an exploitation attempt four days before public disclosure.

What happened

“PHP2Shell” refers to a set of memory-safety flaws that Wiz Research reported to the PHP Security Team on August 24, 2026. After a fix coordinated with Linux distributions and long-term support (LTS) vendors, PHP published fixed releases and two security advisories on October 21, 2026. According to Wiz, every PHP version released in the last ten years contains at least one of these defects, and some go back as far as PHP 5.4.

What makes this so sensitive is reach: PHP runs a very large share of the web, from WordPress to Drupal and Joomla. Yet the vulnerability does not depend on any application. Wiz notes that even a simple “Hello World” page on an affected version can be enough to expose the server.

Technical analysis

All variants share one root cause: mishandling of fatal errors, especially out-of-memory (OOM) errors, during request processing. A fatal error can leave corrupted internal state behind, which a later request handled by the same worker then reuses.

CVE-2026-109618 — RCE via OOM corruption

PHP uses longjmp() to leave the current context on an OOM error. If that happens while request memory is only partly initialized, shutdown can read or act on invalid state. The official advisory says the attack was validated over HTTP against mod_php with default limits. The fix removes this longjmp() path in favor of a deferred “soft” OOM and an immediate _exit() above a higher threshold.

CVE-2026-109619 — RCE via stale global state

PHP workers keep global state (error, session, object and extension state) that can point to memory owned by a previous request. If a fatal error (OOM or timeout) interrupts the request before that state is reset, the memory is freed but the reference survives: a use-after-free (CWE-416) that the next request can exploit. The advisory confirms impact through the PHP 8.5 fatal-error backtrace path (mod_php) and the session upload progress path (mod_php and PHP-FPM).

Four bugs, two CVEs

Wiz describes four bugs grouped under these two identifiers. They enabled unauthenticated code execution demos against the official wordpress:latest, drupal:latest and joomla:latest images, as well as a worker memory leak returned in a PHPSESSID cookie, even when the application never calls session_start().

The role of AI

Wiz says it used frontier AI models for discovery, exploit development and patch validation. According to the company, a single researcher completed in about a week work that would have taken a top-tier team months. Amazon draws the same lesson from the defender’s side: AI-assisted analysis makes it far cheaper to turn a patch or advisory into a working exploit.

Exploitation in the wild

Amazon Threat Intelligence reports that an exploitation attempt hit its MadPot honeypot network on October 17, 2026, four days before disclosure, from an IP address tied to a commercial anonymization service. How the actor obtained the details during the embargo is unknown. On October 21, between 02:00 and 08:00 UTC, further attempts with varied payloads and infrastructure suggested multiple actors. After release, new proofs of concept appeared within hours and were used almost immediately.

Observed requests are multipart POSTs containing the string PHP_SESSION_UPLOAD_PROGRESS. Amazon published six observed IP addresses, stressing that they belong to shared anonymization infrastructure: use them as investigation leads, not as a blocklist.

Who is affected

Any organization running web-exposed PHP: WordPress, Drupal or Joomla sites, intranets, line-of-business apps, back offices. Risk is highest for Apache with mod_php, but PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are also affected. Versions 8.1 and older are no longer supported by the project; minimal backports exist for PHP 7.4, 8.0 and 8.1 for those building from source, and some distributions and LTS vendors ship patched packages.

The most lasting danger is the long tail: forgotten installations, appliances and embedded devices that include PHP without their operators knowing. The UK NCSC asks organizations to take offline any system that cannot be patched or mitigated quickly.

MITRE ATT&CK view

The sources do not provide an ATT&CK mapping. The table below is an indicative Defensy reading based on the behaviors described by Amazon.

Recommendations

1. ImmediateUpdate PHP, starting with exposed systems

   Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or apply your distribution’s patched package. Prioritize internet-facing servers. No configuration change alone fully fixes both CVEs.

2. ImmediateInterim measures while patching

   Enable your provider’s WAF rules (Cloudflare offers them to all customers). Consider session.upload_progress.enabled=0 and, on PHP 8.5, fatal_error_backtraces=0, or blocking multipart uploads after assessing impact. Otherwise, take the system offline.

3. ImmediateInventory every PHP instance

   Web servers, containers, base images, appliances and third-party services. Use a testing tool such as php2shell-scanner (Searchlight Cyber) on hosts you are authorized to test.

4. Short termHunt for compromise back to October 17

   In web logs: POSTs containing PHP_SESSION_UPLOAD_PROGRESS, unusual multipart uploads followed by memory-limit errors, bursts of HTTP 500, oversized PHPSESSID cookies. On hosts: unexpected child processes of PHP workers, modified files, web shells.

5. Short termTrack third-party vendor advisories

   Firewalls, gateways, hosted CMS: watch bulletins from Palo Alto Networks, Fortinet, Cisco and others, and apply their fixes as soon as they ship.

6. Medium termShorten critical patch timelines

   For critical internet-facing vulnerabilities, measure time-to-patch in hours, not days. Build behavioral detections that do not depend on CVE-specific signatures.