Most people file a PHP vulnerability under "web hosting." That filing is wrong. It is a custody problem wearing a sysadmin costume.
The disclosure that circulated on Wednesday carried four numbers and zero identifiers. Two PHP vulnerabilities. Present in the codebase for more than a decade. Exploited in the wild before the vendor research went public. And 22.6 million exposed instances, sitting inside a claim that PHP powers "70% of the internet."
Read that again as an engineer. There is no CVE number. No affected version branch. No patch version. No statement from the PHP Group. The named sources โ Amazon, Palo Alto's Unit 42, Wiz, NCC โ are all commercial security vendors, and not one of them published a reproduction. That absence is more informative than the numbers. A threat-intel newsflash without a CVE is not a disclosure; it is a marketing event with a technical pretext.
I have spent enough hours inside circuit constraints and deploy pipelines to recognize the shape. It looks like a number engineered to travel.
Context
PHP's attack surface was never designed. It accumulated.
Three server APIs coexist in production: mod_php, the CGI binary, and PHP-FPM. Each carries a different exposure model. mod_php inherits the web server's request parsing. FPM speaks a binary protocol over a socket that is, on a shocking number of hosts, bound to 0.0.0.0:9000 with no upstream filter. The CGI binary takes a query string and executes it as a process. Add the X-Powered-By header, enabled by default in most distributions, and you get a fingerprint any scanner can harvest in a single request.
The technical class most consistent with the reported facts is CGI argument injection. The mechanism is worth spelling out because it explains why these bugs survive a decade. PHP's CGI handler performs a "best-fit" character mapping on incoming data โ a legacy concession to Windows codepages. A byte sequence in a query string that maps to a soft hyphen gets reinterpreted by the child process. If that reinterpretation lands on a leading hyphen, the string becomes a command-line switch. A URL becomes an argument. An argument becomes execution.
I am not asserting this is that CVE. The reporting stripped the parameters required to confirm it. But the pattern fits: exploit-before-disclosure, long dormancy, mass exposure, zero version detail.
Then there is the lifecycle. PHP's release branches exit security support on a fixed cadence. 8.1 is out. 8.2 and 8.3 are on the clock. Every disclosure therefore lands on a population that has already stopped receiving patches โ not because operators refused, but because nobody told them the branch was dead.
The four-gate filter
The severity filter has four gates, and the reporting mentioned only the first. A PHP site is actually exploitable when four conditions intersect: the version is vulnerable, the reachable SAPI can trigger the path, the entry point is exposed to the internet, and no reverse proxy or WAF terminates the payload first. Multiply those probabilities and 22.6 million collapses into something plausibly one to two orders of magnitude smaller. That number is still large. It is simply not the number that got published.
The 70% deserves the same surgery. 70% is a stack-penetration statistic, not an exploitability statistic. It is the W3Techs-style share of websites whose server-side language is PHP โ a measure of what people installed, not what can be broken. Wiz's exposure count and the 70% figure use different denominators and are presented side by side, and the adjacency performs work the data does not. Two true statements, stacked, produce one false impression. That is not a technical error. It is a rhetorical technique, and it works because most readers will not run the division.
One more note on the reporting itself. There is no publication year attached โ "Wednesday" is a day, not a date. That is the signature of aggregation: a primary item refracted through secondary coverage until the identifiers fall off and only the impressive digits survive. Treat the article as a signal about what vendors are currently selling, not as a record of what happened this week.
Where crypto sits inside that population
Token project sites. Documentation portals. Airdrop claim pages. Affiliate and IB back-offices. OTC desk intake forms. Legacy exchange admin panels โ the ones written in 2017 by a contractor, still running, still holding a database credential for the KYC vendor's staging environment. NFT mint front-ends behind a WordPress install with eleven plugins, four of which were abandoned two years ago. Support desks. Blog subsites. Each of these is a PHP process, and almost none of them appear on a security team's asset register.
I have been inside this specific failure. In 2021, while the market was bidding on JPEGs, I was forking OpenZeppelin to compress calldata for batch transfers. The contract work was clean. The deploy pipeline was not. A GameFi client's release process ran through a shared-hosting control panel โ the same cPanel box serving their marketing site, their whitepaper PDF, and their Discord verification bot. The signing key was not on that box. The deploy key that could push to the box that held the signing key was. Nobody had drawn that graph, because the graph crossed an organizational boundary between marketing and engineering, and no one owned the edge.
That is the actual threat model. A webshell on a token project's blog is not an incident. It is an on-ramp. The artifacts sitting on a compromised PHP host are not glamorous: .env files with RPC endpoints and provider API keys, keystore JSON, SSH keys, CI tokens, Slack webhooks, and โ in three separate reviews I have done โ a plaintext file named something like wallet_backup.txt inside public_html. The lateral path from a web tier to a signer is usually two hops and a shared filesystem.
Compare that to what I was doing in 2019, auditing zkSNARK constraint systems for the Sapling upgrade. Forty hours into the circuit, I found an edge-case failure in large field element arithmetic that produced silent state corruption under specific load conditions. Silent. That word is the point. A proof that verifies incorrectly is worse than a proof that fails, because the failure mode is invisible. The same pathology governs patch management. An unpatched host that is not being exploited produces no signal. An exploited host that has been cleaned produces no signal. The absence of an alert is not evidence of safety; it is evidence of instrumentation debt.
And instrumentation debt has an owner, or rather, it does not. Ask who actually distributes PHP patches to those 22.6 million instances. It is not the PHP Group. It is the control panel vendor shipping a frozen image, the shared host pinning a branch for compatibility, the CDN terminating TLS in front of it, and the agency managing the site. The entities with real patch-distribution authority over the PHP ecosystem sit almost entirely outside its governance. They carry no contractual SLA to the site owner, no liability for the delay, and no share of the benefit. They function as an unaccountable safety regulator for a material fraction of the internet.
The commercial response is already visible, and it is not a language fix. It is managed hosting: platforms that bundle runtime patching into a subscription because the site owner will never do it themselves. That model works โ it just relocates the trust anchor from the PHP Group to a hosting vendor, which is a different counterparty risk dressed as a solution.
The vendor economics reinforce the pattern. Vulnerability research feeds a free scanner, the scanner feeds registrations, the registrations feed an ASM or CNAPP subscription. That flywheel is not dishonest โ the research is real and the products work โ but it means the disclosure's primary output is pipeline, and the numbers are top-of-funnel assets. A figure that is 30% too high costs the vendor nothing and buys a great deal of coverage. Peer review would cost them a week and a headline.
There is an on-chain version of this, too. I have watched a DAO approve a five-figure annual hosting invoice from a multisig without a single delegate asking which runtime version it was paying for. Treasury transparency stops at the payment rail. What the money buys remains unaudited.
The contrarian read
The counter-intuitive conclusion is that the RCE is the least interesting part of this story.
Composability isn't free. We celebrate it in DeFi because the market prices failure in seconds โ a bad oracle, a drained pool, a liquidation cascade, all visible and settled on-chain. In an operations stack, composability means uncorrelated components whose failures correlate anyway. A CMS plugin, a SAPI, a control panel, a CI runner, a signer. Each link is defensible in isolation. The composition is not, and nobody is accountable for the composition, because accountability is organized by component.
The blind spot is detection, not patching. NCC's warning that vulnerable systems may already host backdoors was the actual headline, and it arrived as a subordinate clause. If exploitation predates disclosure by an unknown interval, version-bumping is remediation theater โ closing the door after someone has already copied the keys. The correct first action is retrospective: IOC sweeps, outbound traffic baselines, and a hard look at anything that touched a signing path since the earliest plausible compromise date. Almost nobody does this, because it is expensive and produces ambiguous findings.
The PHP supply chain is an ecosystem in the biological sense rather than the marketing sense: dense, adaptive, and indifferent to the health of any individual host. Security is an ecosystem property. No single participant can make it safe, and every participant can make it unsafe. That asymmetry is what regulation is for.
Which brings the regulatory clock. The EU Cyber Resilience Act entered into force in December 2024, with reporting obligations in September 2026 and full applicability in December 2027. Pure open-source projects are carved out. Commercial integrators are not. Translated: the exchange that bundles a PHP runtime into a product, the host that pins a dead branch, and the vendor shipping a frozen appliance inherit the liability the upstream never carried. We don't patch what we can't inventory โ and the liability is being reassigned faster than the tooling to satisfy it is being built.
Takeaway
The forward-looking judgment is narrow and testable. Within eighteen months, "what version is running on this box" stops being a question answered by a human reading a phpinfo() page and becomes a procurement line item: signed attestations, VEX documents, and eventually verifiable build provenance. Teams that treat runtime inventory as an attestation problem rather than an audit chore will absorb the CRA transition as paperwork. The rest will absorb it as a finding.
The next PHP RCE is not a matter of if. It is a matter of whether, when it lands, your answer to "which hosts" arrives in minutes or in a spreadsheet three weeks later.
