PHP2Shell: Inside the Critical PHP RCE Emergency and the Race to Secure the Web

The unofficial “php2shell” crisis shows how much of the modern web sits on aging runtimes. On October 20, 2026, a Hacker News post alleged two critical remote code execution vulnerabilities deep in the PHP core, tracked as CVE-2026-109618 and CVE-2026-109619.

How a rumor became a confirmed emergency

The first claims were chaotic. The post suggested a CVSS score of 10.0 and said every version back to PHP 5 was affected. The author also admitted that none of it was independently verifiable and that it rested on unverified rumors.

PHP is everywhere, so security teams treated the post as a tier-one emergency anyway. Enterprises and managed hosting providers began inventory checks before any vendor had confirmed a thing.

The rumor firmed up quickly. Research firms including watchTowr and Sansec independently confirmed the remote code execution flaws and validated the CVE identifiers. CERT-EU then issued an urgent advisory confirming the vulnerabilities, scoring them 9.2 on CVSS v4.0 and telling organizations to prepare for immediate remediation. The coordinated disclosure timeline could not survive the public leaks, so the PHP team dropped its standard release schedule and announced an emergency out-of-band patch for October 21, 2026. It added that the release could come sooner if exploitation showed up in the wild.

Why a core runtime bug sits below your application defenses

Application security and runtime security are different problems, and many enterprise programs only cover the first. When you patch a flaw in WordPress or Laravel, you are fixing logic that runs after the server environment is initialized, the database connections are open, and the request has passed through middleware.

A vulnerability in the PHP core, in the Server API (SAPI) layer or the Zend Engine itself, sits underneath all of that and runs before your code gets control of the thread. In a typical deployment, Nginx or Apache receives the HTTP request and hands the raw byte stream to PHP-FPM or another FastCGI process manager over a local socket. PHP then parses the headers, interprets the body, initializes the execution environment, allocates memory for the request lifecycle, and populates superglobals like $_POST, $_GET, and $_FILES. All of that happens before the first line of application code.

So if an exploit triggers during request parsing, your application controls never get a chance to act. Input validation, strict routing, parameterized queries, and authentication middleware all do nothing if the interpreter crashes or executes a memory payload while trying to understand the request structure. Web Application Firewalls at the network edge have the same blind spot when the flaw depends on multi-stage memory corruption that leaves no recognizable string signature in the headers.

The multipart and upload-progress theory

Early technical theories about php2shell center on PHP’s handling of multipart/form-data requests and the session upload-progress mechanism. This code processes raw binary data before any application-level sanitization can happen.

Multipart encoding, originally defined in RFC 1867, is how browsers send files alongside ordinary form fields. The server has to parse boundary strings, MIME headers, and content blocks straight off the TCP stream. PHP does this automatically to populate $_FILES, and the C parsing logic in main/rfc1867.c runs on any endpoint that accepts POST requests, whether or not the application handles uploads.

The mechanism getting the most attention from reverse engineers is session upload-progress, a native feature that lets clients track large uploads asynchronously. With session.upload_progress.enabled turned on, PHP intercepts multipart uploads and keeps updating session data with transfer status. Internal C functions such as php_session_rfc1867_callback() manage the state transitions and serialize the progress data into the session handler.

Researchers, including one working under the handle JackalSyn, theorize that this callback has a memory-lifetime defect that produces a use-after-free. If so, a specially crafted, malformed multipart request could corrupt the engine’s internal state.

How a use-after-free works in the Zend Engine

To see why this matters, you need the Zend Engine’s memory model, which wraps C-level memory operations in reference-counted containers. Every variable, array element, and object property is a zval (Zend value), which holds the data or a pointer to it plus a type union and metadata. For strings, arrays, and objects, the zval points to a zend_refcounted header that counts how many variables reference that block. When the count hits zero, the engine calls efree() and returns the memory to the allocator.

A use-after-free happens when the runtime frees a block but keeps a stale pointer to it. The usual cause is a logic error in a callback that fails to increment a reference count or fails to nullify the pointer after the structure is destroyed. An attacker who can shape the heap, often by heap spraying with thousands of controlled POST parameters, can get the allocator to reuse that exact address for a malicious payload. The next time the engine touches the stale pointer, it works with attacker-controlled data.

For the upload-progress callback, that would mean the engine reads or writes session data through a pointer that now references an attacker-controlled HashTable or a fake zend_function structure injected through the multipart boundary strings.

From memory corruption to a shell

Turning a use-after-free into reliable remote code execution in a managed runtime takes extreme precision. The attacker has to get past strict type controls, address space layout randomization (ASLR), and the engine’s internal dispatch mechanisms.

The Zend Engine invokes internal and user-defined callables through structures like zend_call_function(). Corrupting the data that drives that dispatch could let an attacker hijack the instruction pointer, for example by overwriting a function pointer or altering the internal representation of a callable array. The engine then runs arbitrary system commands, and an ordinary web request becomes a remote shell. That chain is where the “php2shell” name comes from: the end payload is typically a webshell or a reverse shell launched from the compromised PHP-FPM worker, with the privileges of the web server user.

Modern PHP exploit development adds more hurdles. The attacker has to deal with the Just-In-Time (JIT) compiler’s memory layouts and the separation between the request-bound allocator (emalloc) and the persistent process allocator (pemalloc). The corrupted pointers have to survive request cleanup and still be usable when the code runs.

The audit that disputes exploitability

The public analysis is not unanimous. A separate technical audit of the PHP source argued that modern reference management, specifically the Z_TRY_ADDREF macro, keeps the relevant arrays alive during upload-progress tracking. If that is right, the proposed memory-lifetime defect does not exist in officially released builds.

The auditors noted that when they removed the reference-management operation in a custom test build, AddressSanitizer (ASan) flagged the problem and the crash reproduced. The same conditions did not materialize against unmodified, production-grade PHP binaries built with standard optimization flags.

That gap matters. A bug that is easy to exploit in a debug build with mitigations disabled can be unworkable in a hardened, optimized release. It is also a reminder to be careful with unverified proof-of-concept code. Until the official release notes map the CVEs to specific source commits, I would treat the upload-progress use-after-free as plausible but unconfirmed. The actual patch could touch different subsystems or alternate parsing routines in the SAPI layer that haven’t been disclosed.

How many hosts are exposed

Whatever the exploitation mechanics turn out to be, internet-wide scanning data shows a large remediation problem. Rapid-response telemetry from Mallory found roughly 884,000 internet-facing hosts advertising PHP 8.1 or older in their HTTP banners. Another 1.5 million hosts reported some version of PHP without saying which one. That is a big shadow fleet of end-of-life runtimes that no longer get upstream security patches.

Under the official PHP supported-versions policy, branches such as PHP 8.1 have reached end of life. Even if the vendor confirms these vulnerabilities affect older codebases, no official patches will ship for those branches. Millions of sites stay exposed unless their owners complete a complex migration.

Deployment fragmentation makes it harder. Developers rarely manage the PHP runtime directly. It is bundled into container base images, controlled by hosting panels like cPanel, or installed through operating-system package managers that may apply their own backported fixes. An administrator can run a version check on a workstation and see a patched build while the PHP-FPM pool serving production traffic runs a different, vulnerable binary managed by another team. You have to inventory every execution path.

Temporary mitigations if you cannot patch yet

Teams that cannot patch or migrate right away have a few compensating controls, though all of them are fragile and narrow.

If the final vendor advisory confirms the flaw depends on the session upload-progress mechanism, setting session.upload_progress.enabled = Off in the active php.ini or FPM pool configuration should cut the attack path. The engine would no longer invoke the vulnerable callback during multipart parsing. This only works for that one path. If the CVEs reach the baseline RFC 1867 implementation beyond the upload-progress callback, the memory safety defects in core multipart parsing stay unfixed.

Blocking multipart requests entirely at the WAF or reverse proxy is risky. It tends to break legitimate integrations, third-party webhooks, and ordinary file uploads, and the resulting availability problems can hurt as much as the incident. Generic multipart filtering is also easy to bypass: attackers can chunk payloads or manipulate boundary strings to slip past regular-expression WAF rules. Network-level defenses are a poor match for memory corruption inside the interpreter’s trusted execution boundary.

Detecting exploitation

Catching exploitation of a memory corruption bug in a busy PHP environment takes more than WAF logs and HTTP status codes. A successful use-after-free attack rarely produces a 500 Internal Server Error. The payload runs silently while the PHP worker returns a normal 200 OK, so standard application performance monitoring sees nothing.

Defenders need endpoint telemetry and process lineage monitoring instead, such as eBPF on Linux or advanced ETW providers on Windows, to watch the web server’s execution tree. A PHP-FPM worker should almost never spawn interactive shells, network downloaders, or system utilities. If sh, bash, curl, wget, or PowerShell shows up as a direct child of a PHP process, treat it as a strong indicator of compromise. Tools that monitor PHP process lineage can alert the moment a web worker tries to run an unauthorized binary, which may give you the seconds you need to isolate the host before lateral movement starts or database credentials leave for a command-and-control server.

Forensics after patching

A patched server is not necessarily a clean one, so remediation has to include a forensic sweep for persistent backdoors, modified application code, and database credentials harvested from environment variables before the patch landed.

Filesystem and network telemetry can show post-exploitation activity. Huntress has documented earlier FastCGI compromises where attackers wrote randomized PHP files into writable temporary directories, ran them in memory, and deleted them right away to evade file integrity monitoring. On the network side, DNS logs, firewall events, and proxy records can show whether a compromised PHP process contacted an unfamiliar external host, pulled more payloads, or talked to unexpected internal services.

Preserve volatile memory and execution state on suspected systems before you rebuild them. The memory layout and allocator state at the time of the crash can reveal the exact exploitation primitive, which helps the wider community refine detection signatures and judge what the php2shell chain can actually do.

FastCGI and the SAPI attack surface

The FastCGI protocol and the PHP SAPI layer make a distinct attack surface that could amplify memory corruption flaws like the ones alleged here. Nginx does not pass raw HTTP bytes to PHP-FPM. It wraps the request in the FastCGI binary protocol, using record types such as FCGI_PARAMS for environment variables and FCGI_STDIN for the request body. The SAPI layer unpacks those records, rebuilds the HTTP environment, and feeds the result to the Zend Engine’s request initialization hooks.

If the SAPI layer mishandles malformed FastCGI records or unexpected stream terminations during a multipart upload, an attacker might trigger a heap overflow or use-after-free before the HTTP request is fully reassembled. A network WAF that only inspects the reconstructed HTTP payload would never see it. The risk is higher where PHP-FPM is exposed directly to the internet, a dangerous misconfiguration that still turns up in legacy cloud deployments. There, an attacker can skip the web server and speak FastCGI to the PHP-FPM socket directly, injecting parameters or manipulating the execution environment and getting a straight path to the operating system.

Why containers complicate patching

Containerized deployments and immutable infrastructure make patching harder because they hide the true state of the runtime. In Kubernetes, the PHP interpreter is baked into a base image. An emergency patch means rebuilding the image, pushing it to a registry, and orchestrating a rolling restart across the fleet.

If you depend on a third-party base image or a legacy vendor appliance that hasn’t picked up the upstream fixes, your infrastructure team is blocked. The options are to fork the image and compile the patched PHP from source, or to live with the exposure. That delay hurts most when exploit code could circulate within hours of the vendor announcement.

Ephemeral containers add a forensic problem. The orchestrator may terminate and replace a compromised PHP-FPM worker before anyone collects evidence, and the attacker can simply retry against the next pod. Admission controllers that reject images containing known vulnerable runtime versions help. So do runtime security platforms that inject eBPF probes into the container namespace to watch for the allocation patterns and anomalous process lineages tied to the php2shell chain, so the move to cloud-native architecture does not leave defenders blind at the execution layer.

Reducing the blast radius

Security teams spend heavily on software bills of materials for third-party JavaScript libraries and on scrutinizing application dependencies, yet often lack basic visibility into the version of the C interpreter running their critical business logic. php2shell exposes that gap.

To limit the damage from future runtime vulnerabilities, isolate PHP services with Linux namespaces, cgroups, and strict seccomp profiles. Even if an attacker gets arbitrary code execution inside the PHP-FPM worker, they should land in a restricted sandbox with no access to the wider host filesystem or the internal network. Secrets management matters as well. Database accounts should hold only the privileges the application’s queries need, and cloud credentials should come from short-lived managed identities instead of static environment variables that a compromised worker can dump.

I would go further and treat the PHP runtime as an untrusted boundary that is always at risk of memory corruption. Designing around that assumption keeps a single flaw in the Zend Engine’s reference counting from becoming a total compromise of the enterprise.

What the embargo collapse shows

The php2shell timeline also raises questions about coordinated vulnerability disclosure. CVD depends on trust between researchers, vendor maintainers, and downstream distributors. It gives enterprise defenders a window to test patches and prepare deployment pipelines before technical details go public.

When an embargo breaks early, whether through a careless social media post, a misconfigured bug bounty platform, or deliberate sabotage, downstream teams scramble. They deploy unverified mitigations and make high-stakes architectural decisions with incomplete forensic data. This incident suggests that for foundational technologies with huge deployment footprints, a 90-day disclosure window no longer fits the pace of automated exploitation, where weaponized proof-of-concept code can be generated and distributed globally within minutes of a source commit reaching a public repository.

Vendors of critical infrastructure components need real-time communication channels with enterprise defenders. When an embargo breaks, they should publish actionable telemetry and verified mitigations immediately, because a static advisory page cannot keep up with a live zero-day.

The memory-safety debate returns

Repeated memory corruption bugs in PHP’s C codebase have revived the argument for moving foundational web infrastructure to memory-safe languages like Rust. The PHP core team has historically resisted, given the size of the existing C codebase.

The team has kept improving the engine’s internal safety with stricter type hinting, automated reference counting audits, and static analysis tools that catch lifetime defects before release. Manual memory management in C still means the attack surface cannot be eliminated. Each new feature, from JIT compilation to fiber concurrency, adds new chances for pointer mismanagement and state desynchronization.

Enterprise architects are now weighing the ongoing cost of defending and patching legacy C-based runtimes against the engineering investment needed to rebuild the web’s execution layer in memory-safe environments. If php2shell is any guide, that comparison will come up more often.