PHP2Shell: WTF Happened? (CVE-2026-109618 and CVE-2026-109619)

The response window was short because the embargo came apart in public, and this is the part that earned the "WTF happened" reaction.

The research had been quiet for weeks. Calif reported an initial flaw to PHP in August, and Wiz Research reported the vulnerabilities to PHP on August 24, with OpenAI's security team credited in the coordinated effort. The fix was hard to build, and the coordinated disclosure was scheduled for October 22.

Then the embargo broke in stages. On October 20, the two CVE identifiers began circulating on forums and social media with incorrect severity and timing attached; at that point the identifiers were public, not the technical details. Shortly after, Calif accidentally published a video that contained a working proof-of-concept, which did expose technical material and contributed to faster independent exploit development. Mitigation advice the PHP Foundation had shared privately with critical-infrastructure organizations may also have leaked. With the embargo visibly breaking, PHP pulled its release forward one day, to October 21.

The third exposure became a public dispute, and it is worth stating both positions plainly. The PHP Foundation characterized Chainguard's publication of fixed container images, at 07:41 UTC on October 21, roughly six hours before the coordinated release, as breaking the embargo: "Any attacker could now study the fix in binary form while every other PHP user was still waiting for the release," adding that it "disregarded weeks of work by many parties toward a coordinated disclosure." Chainguard's CEO, Dan Lorenc, responded that the company leaked nothing, did not dispute the timeline, had independently discovered the same vulnerabilities using its own AI tooling, and had helped test the patches. The two claims are not mutually exclusive, and the PHP Foundation has not publicly answered the independent-discovery account.

The mechanism behind the Foundation's complaint is a recurring supply-chain problem worth understanding. When a patched binary ships before the advisory, anyone can compare it against the previous build, locate the changed code, and work backward toward the flaw. Patch-diffing can turn a fix into a map of the bug. Publishing a fixed binary ahead of an advisory does not, on its own, establish that the publisher was the source of the leak or that every attacker used that path, but it can lower the barrier for those who do.

Exploitation does not map neatly onto the patch timestamp. Security vendors reported exploitation attempts before the patches landed, with some reporting activity dated to October 17, and Cloudflare observed attack traffic and said some attackers adapted payloads to evade its WAF rules. On October 21, Cloudflare had rules enabled by 03:02 UTC, PHP shipped the fixes around 14:00 UTC, and watchTowr moved from reporting no observed exploitation to active attempts against both CVEs within minutes of the release. These are different observations, not necessarily one campaign, and early samples, demonstrated chains, exploitation attempts, and confirmed compromise are not the same thing. As of the initial reporting on October 21, no confirmed breach had been published and neither CVE was in CISA's Known Exploited Vulnerabilities catalog, though several organizations, including BambooHR and some Dutch government and education sites, took services offline as a precaution. Treat that status as time-bounded and recheck it before acting.

The practical lesson is that the patch-release timestamp is not when the threat began. Public research and exploit tooling sharply reduced the work an attacker would otherwise have needed to reproduce the demonstrated attacks. That did not make every deployment equally exploitable, but it shortened the path from disclosure to practical attempts, and it means any system exposed beforehand needs investigation, not a patch alone.

What an Unpatched Server Faces

For an unpatched, internet-facing server, two kinds of outcome follow, and the first needs no code execution. The memory-disclosure path can return freed worker memory in the response, exposing secrets from other requests the same worker handled, such as session tokens and API keys. It may leave no obvious application-level error, so responders should examine web-server and proxy telemetry alongside PHP logs and process activity rather than expecting a clear log entry.

The second outcome is full remote code execution, and from there the familiar chain follows: a web shell, credential theft, lateral movement, data exfiltration, or staging for ransomware. The old-version problem makes this durable in specific places. End-of-life branches will never receive this fix, and PHP that is bundled into an appliance, an embedded device, or a vendor product may have no patch at all without the vendor, which makes inventory and supplier coordination the real work rather than an afterthought.

Detection and Threat Hunting

Because the trigger is request parsing and the effect is memory corruption, the observable signals cluster around malformed uploads and unstable workers. For a server that may have been exposed before patching, investigate:

• Unusual multipart/form-data requests, especially ones followed closely by memory-limit errors in the PHP logs.

• Repeated HTTP 500 responses, which accompany the fatal errors the first bug depends on.

• Unexpectedly large or malformed PHPSESSID values in server responses. This is where the memory-disclosure path surfaces, so it is an outbound response artifact, not an oversized cookie arriving from the client.

• Unexplained PHP worker restarts, which can follow a failed or partial exploitation attempt.

None of these is conclusive alone. Judged against the application's normal baseline, a cluster of oversized multipart requests, memory-limit fatals, and worker churn against an unpatched server is a high-priority investigation lead. A successful memory-corruption exploit may not produce the same symptoms as an ordinary error, so corroborate across web-server, proxy, and PHP logs plus process telemetry rather than relying on one pattern.

Responding to PHP2Shell: Priority Order

For an exposed environment, act in this order:

1. Identify and patch. Find every internet-facing PHP runtime, including those bundled in containers, appliances, and third-party products, and apply the vendor-fixed release. Updating the application framework does not fix the runtime.

2. Reduce exposure while patching. If an immediate update is impossible, restrict public access or isolate the affected service. Treat WAF rules and PHP configuration changes as temporary risk reduction, not complete mitigations.

3. Investigate possible compromise. Review web, proxy, and PHP logs, endpoint telemetry, unexpected processes, modified files, and suspicious outbound connections. Patching does not establish whether an attacker accessed the system beforehand.

4. Verify the result. Restart the relevant services and workers, confirm the running runtime is a fixed build, and check vendor advisories where fixes are backported.

Interim Mitigations and Their Limits

The PHP project is explicit that there are no complete mitigations and that updating is the only safe choice. The measures below reduce exposure to specific paths; they do not make an unpatched runtime safe. Restart the affected PHP workers and relevant serving processes after applying configuration changes, as your deployment requires. Verify the current recommendations in the PHP Foundation's security release post rather than relying on a summary.

For CVE-2026-109618, PHP recommends setting memory_limit to -1 through configuration that applications cannot override, such as the FPM pool or Apache config, which removes the controllable memory-limit trigger. This is not a casual change: it removes PHP's per-request memory cap, so a single request can consume substantial system memory, and external request limits alone do not guarantee the vulnerable allocation path cannot be reached. Blunt the denial-of-service risk by keeping post_max_size low and upload_max_filesize below it, enforcing request-size limits at the proxy, and placing a container or cgroup memory boundary around the worker that can terminate it. Do not substitute RLIMIT_AS or RLIMIT_DATA, which recreate the allocation failures that reach the bug.

For CVE-2026-109619, PHP recommends disabling session upload progress to block confirmed session-related exploit paths. Set session.upload_progress.enabled to 0 at the pool or server level so it applies before request parsing, then restart workers; setting it through ini_set() or a .user.ini is too late to help. On PHP 8.5, also set fatal_error_backtraces to 0 to block the confirmed fatal-backtrace path. These settings address specific paths, not every possible variant, and do not make an unpatched installation safe.

A post-patch note, per the reporting on the fix: it introduces a hard memory limit that can terminate a process without running PHP shutdown handlers. If your logic depends on shutdown functions or graceful memory-exhaustion handling, confirm the patched behavior against the PHP release notes before assuming it matches the old one.

What This Means for Inventory and Response

PHP2Shell is, operationally, an inventory problem before it is a patching problem. On October 21, the first question for most teams was not how the bug works. It was: where do we run PHP, which versions, and which products, services, and customers are exposed.

A current, sufficiently complete software bill of materials helps answer that by identifying the products, builds, and images that contain the affected PHP runtime. It is where PHP tends to hide: bundled inside appliances and embedded web interfaces, baked into container base images, pulled in as a dependency of a larger product, places a manifest-level scan tends to overlook. An SBOM is only as good as its coverage. It points you at the assets worth checking; it does not by itself confirm the exact version running in production or prove a given host is exploitable. When SBOMs are current and capture the relevant runtime, they turn a days-long census into a much shorter list of assets to verify.

Interlynk is built for this pattern. lynkctl generates build-aware SBOMs that capture the runtimes and components embedded in firmware, appliances, and images, well beyond the top-level dependencies. The Interlynk platform ingests those SBOMs, risk-assesses components against vulnerability data so an affected PHP version surfaces automatically, manages VEX assertions for the products you have assessed, and notifies stakeholders when a new disclosure changes the exposure of something already shipped. When the next runtime-level CVE lands, the inventory is already in place.

The Bottom Line

PHP2Shell shows how a memory-safety defect in a widely deployed runtime can undermine the security of applications that did nothing wrong. Two memory-safety flaws present in PHP for more than a decade were developed into unauthenticated remote code execution, and a coordinated disclosure that fell apart left defenders with almost no grace period.

Patch the runtime to 8.5.12, 8.4.27, 8.3.36, or 8.2.35, restart your workers, verify by CVE ID, and investigate anything exposed before the patch. Then make the inventory question answerable in advance, because when a vulnerability lives in a runtime shared across thousands of products, knowing where that runtime is deployed is part of incident response, not cleanup afterward.