Two CVSS 9.2 memory-safety bugs in PHP core, exploited in the wild four days before disclosure
PHP2Shell: The Patch Is the Only Fix
Can any mitigation short of patching stop an unauthenticated RCE that runs before your application code?
Two memory-safety flaws in PHP core, tracked as CVE-2026-109618 and CVE-2026-109619 at CVSS 9.2, let unauthenticated attackers run code before application code executes. The record from four vendor research posts says the same thing: patch, because nothing else closes it.
Interactive research edition · 16 register rows · every figure traces to a dated source · SARVINS Bytes
PHP2Shell · Summary
PHP2Shell is an unauthenticated RCE in PHP itself, and patching is the only complete fix
Two memory-safety flaws in PHP core earned CVSS 9.2 and were exploited before disclosure. The thesis: because the vulnerable code runs before any application code, no application-layer control — authentication, app-tuned WAF logic, or the community's config tweaks — substitutes for upgrading PHP.
On October 20, 2026, PHP announced a patch for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, scheduled for release on October 21 at 14:00 UTC; details were due October 22 but leaked early. Datadog Security Labs scores both at CVSS v4.0 9.2 and lists the fixed releases as PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, with source backports for 7.4, 8.0 and 8.1.
Wiz Research frames the exposure at 70% of all websites and says every PHP version released in the last decade is affected by at least one of the flaws, going back to 5.4. Datadog independently reproduced the vulnerabilities and confirmed that application-level authentication cannot block an attack, because PHP processes the malicious request before any application code runs.
The practical consequence is narrow and unambiguous: only patching fixes these vulnerabilities, and community mitigations such as setting session.upload_progress.enabled=0 do not fully protect. Everything else in the supplied record is exposure reduction, not remediation.
PHP2Shell · What happened
Exploitation preceded disclosure: October 17 attacks, October 21 patches, October 22 details
The public record runs backwards from the fix. The thesis: PHP2Shell's timeline is a disclosure failure as much as a memory-safety failure — attackers were in the wild four days before patches shipped, and CVE details leaked ahead of the scheduled October 22 disclosure.
PHP announced the patch on October 20, 2026 for release on October 21 at 14:00 UTC, with technical details scheduled for October 22 — but information about the vulnerabilities, including the CVE IDs, leaked early.
Exploitation came first. Per Datadog, AWS reported PHP2Shell exploitation attempts in the wild as early as October 17, 2026, four days before public disclosure and the release of patches. That single sentence is the only in-the-wild evidence in the corpus, and it is second-hand.
Scope is broad by construction: Datadog says any PHP runtime serving HTTP requests is in scope, naming Apache modules, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed, and warning that containers and applications bundling their own interpreter must be inventoried separately from the command-line PHP install. Akamai's prerequisites are equally ordinary — PHP 5 onward with session.upload_progress.enabled=On by default, an endpoint that accepts file uploads, and a build-specific offset the attacker must obtain.
PHP2Shell · Why it matters
Application authentication is not a control here — the exploit runs before your code
PHP processes the malicious request during request initialization, so application authentication never gets a vote. The thesis: PHP2Shell's blast radius is set by PHP's share of the web and by memory disclosure that leaks secrets even without code execution, and frontier AI has lowered the skill floor for building the exploit.
Datadog reproduced the flaws with an unauthenticated HTTP POST request that never reaches the target application's code; PHP runs the attacker's command while it cleans up the failed request. Any PHP script exposes the vulnerable path, even one that only prints a response.
Even without code execution, Wiz demonstrated reading sensitive data from PHP process memory, including passwords, tokens, API keys and certificates belonging to other requests or the server itself. Combined with PHP's 70% share of websites and an affected range reaching back to 5.4, that makes the exposed population large and the detection problem quiet.
Wiz attributes the practical exploitability to frontier AI models, which it says substantially reduced the barrier and let its team adapt working exploits across multiple applications in hours. That claim is the author's own account of its own research, and it is the part of the record most likely to be revised.
PHP2Shell · Verdict
Patch, then inventory: the mitigations reduce exposure but do not close it
Community mitigations such as disabling upload progress do not fully protect, per Datadog. The thesis: the defensible position is to treat PHP2Shell as a patch-or-isolate event — upgrade to a fixed branch, rebuild container images, restart workers, and isolate internet-facing applications where patching cannot happen immediately.
The defensible position is patch-or-isolate. Datadog states only patching fixes these vulnerabilities and that configuration mitigations reduce exposure without closing it; where immediate remediation is not possible, it reports CERT-EU's recommendation to isolate internet-facing applications.
Inventory is the hard part. Datadog warns that containers and applications bundling their own PHP interpreter can differ from the command-line install, and that vendors sometimes backport fixes without changing the upstream version number; the 7.4, 8.0 and 8.1 backports sit outside normal support and will move slower.
What the corpus cannot answer: how many hosts were exploited, how fast patches were adopted, or whether the October 17 date holds up. Two supplied sources — Imperva and Arctic Wolf — yielded no usable content, and no primary PHP advisory text is in the record.
Monitoring · falsification register