At 3:52 PM ET on October 20, the PHP Foundation gave defenders advance notice: two critical vulnerabilities, both scored 9.2 under CVSS v4, would be addressed in new PHP releases the following day.
At 6:11 PM, I shared that warning with a blunt line: “Patch up, its going to be a wild ride!”
That was not a discovery claim. I did not find the vulnerabilities, and I was not claiming exclusive intelligence. The PHP Foundation had already published the primary warning. My judgment was that the signal mattered immediately—not after every advisory had been syndicated, and not after attack traffic became visible.
When a foundational web runtime warns that two critical fixes are hours away, defenders should already be finding affected systems, clearing change windows and preparing rollback plans.
By the next morning, that window had nearly disappeared.
The public sequence compressed in under a day. The IRIS C2 post introduced a retrospective four-month claim without public artifacts; the 14:00 UTC patch window was followed by fixed GitHub releases between 14:06 and 14:09 UTC.
What changed overnight
Later that evening, I shared a post from a security researcher who claimed to have recreated and tested the two vulnerabilities, now identified as CVE-2026-109618 and CVE-2026-109619.
That remains a third-party reproduction claim. A social-media post is not proof of the exact method, reliability or practical reach of an exploit, and I am not treating it as one. The official PHP advisories now independently confirm the underlying issue: both vulnerabilities can lead to unauthenticated remote code execution.
The distinction matters. The official disclosure validates the severity of the flaws. It does not automatically validate every public claim made during the disclosure window.
At 3:43 AM ET, Cloudflare CTO Dane Knecht said the company was seeing “early attacks emerging.” That is meaningful first-party telemetry from a major network operator, but it is still a bounded claim. It does not establish how many systems were targeted, whether attempts succeeded, who was responsible or whether there was a coordinated campaign.
At 9:45 AM, the official, verified @NSACyber account issued a stronger operational warning. It advised organizations using PHP to prepare for the update and said the flaws could provide a direct route to a server’s filesystem or database. If an immediate update was not feasible, NSA recommended taking the affected system offline until it could be fully mitigated. What an attacker could actually reach would still depend on the PHP worker’s privileges and the deployment.
From the PHP Foundation’s advance notice to NSA’s warning, the escalation unfolded in just under 18 hours.
The four-month honeypot claim
One post could move the timeline back much further—but only if the underlying evidence supports it.
At 8:52 PM ET on October 20, the verified IRIS C2 account said it had “caught the PHP exploit 4 months ago” in its honeypots. It also described the follow-on stages as “quite Russian-like.”
That is potentially consequential retrospective telemetry. It is not yet a public demonstration that these exact CVEs were exploited four months before disclosure. The post does not show a capture date, request sample, packet trace, malware hash, infrastructure, target count or the technical basis used to connect the activity to either vulnerability.
The “Russian-like” wording is resemblance language, not attribution. It does not identify a state, service, criminal group or campaign.
The correct response is to preserve the claim without promoting it to a confirmed fact. If IRIS C2 publishes artifacts that bind the honeypot activity to these flaws, the disclosure story changes from an overnight exploitation race to a possible months-long exposure question. Until then, defenders can still use the claim constructively: extend log review where retention allows, preserve suspicious historical crashes and requests, and look for follow-on activity without assuming who was behind it.
Two different routes to the same outcome
The PHP security team describes CVE-2026-109618 as remote code execution arising from memory corruption during an out-of-memory condition. CVE-2026-109619 involves stale global state across requests that can also lead to remote code execution.
Those descriptions are enough for defenders. Publishing operational exploit instructions would add risk without changing the central decision: exposed systems need to be updated.
Both flaws are rated CVSS v4 9.2. Both can be reached without authentication. PHP says installations serving web requests are in scope, although practical exposure varies by deployment model.
Apache module deployments carry the clearest demonstrated risk. The PHP advisory says an application-independent, unauthenticated path has been confirmed there. PHP-FPM deployments are also susceptible, but the demonstrated conditions are more nuanced. That nuance helps with prioritization; it is not a reason to defer patching.
Two internal failure modes converge on the same defender outcome: unauthenticated remote code execution and an urgent need to update.
The fixed versions
The complete fix is to move to one of the patched releases:
PHP 8.2.35
PHP 8.3.36
PHP 8.4.27
PHP 8.5.12
PHP 8.1 and older branches are end-of-life. The project has also provided exceptional, minimal source backports for PHP 7.4, 8.0 and 8.1, while operating-system vendors and long-term-support providers may ship their own packages.
That creates an operational trap. A server can report that its package is current for an old repository while still running an unsupported PHP branch. Teams need to verify the actual runtime version and the provenance of the fix, not simply trust a successful package-manager command.
Supported branches have fixed releases. Older installations need a verified backport or a supported migration path—not an assumption that “current” means safe.
What defenders should do now
Start with inventory. Find every web-serving PHP runtime, including containers, legacy applications, administrative panels, embedded appliances and forgotten internal services that may still be reachable through a proxy or VPN.
Upgrade to the fixed release for the deployed branch, then restart the relevant web servers and PHP workers. Confirm the version loaded by the running web service; checking only the command-line PHP binary can create false confidence when the web stack uses a different package or image.
Review telemetry from the disclosure window forward—and farther back where retention permits. Look for unexplained worker crashes, repeated restarts, unusual requests, unexpected filesystem or database access, and changes that do not match an authorized deployment. Preserve evidence before rebuilding a system that may have been compromised.
PHP has documented temporary configuration changes that may reduce exposure in specific conditions. They are incomplete mitigations, not replacements for the update. The same applies to web application firewall rules. Even the Cloudflare statement that announced new protections explicitly called them a stopgap.
If a vulnerable internet-facing system cannot be patched or reliably isolated, both NSA and the UK National Cyber Security Centre point toward the uncomfortable but defensible option: take it offline until the risk can be controlled.
A WAF can buy time. It does not remove the underlying vulnerability. Patch, restart, verify and investigate the exposure window.
Why the early warning mattered
The useful part of an early warning is not being able to say “I told you so.” It is buying defenders time before a technical problem becomes an operational emergency.
At 6:11 PM, the fixes were not yet public, but the primary source had already made the stakes clear. That was enough to begin locating PHP systems, notifying application owners, preparing maintenance windows and identifying services that could not be patched quickly.
About fifteen and a half hours later, NSA was publicly telling unprepared organizations to consider taking systems offline.
That is the lesson here. In fast-moving vulnerability disclosure, certainty arrives in layers. A maintainer’s advance notice, a honeypot operator’s retrospective claim, a researcher’s reproduction claim, network telemetry, a government warning and a final technical advisory do not carry equal evidentiary weight. Good threat intelligence keeps those layers separate while still acting on the risk they collectively reveal.
The patches are now available. The warning phase is over. The historical exposure question is not.