A security advisory dropped Wednesday with three numbers and zero identifiers. Seventy percent of the internet. 22.6 million exposed instances. Exploited before disclosure.
No CVE. No affected version branch. No patch number. No named victim.
I read it twice. The second pass wasn't for technical content โ there wasn't any. It was to figure out what the number 22.6 million was actually counting. It's a scan-visible host count, not an exploitable-surface count, and the two differ by an order of magnitude.
In crypto we have a clean name for a headline with no order book behind it. We call it a liquidity mirage. The quote looks real until you try to fill it.
This one is worse than a mirage, because it is directionally true. Something is exposed. A lot of somethings. The problem is that the advisory handed operators a number they can't act on and a threat they can't size โ which in my experience produces exactly one outcome: a two-week panic, a budget spike, and nothing patched by Q3.
Here's the structural background the advisory assumed you already had.
PHP is the default runtime of the shared-hosting era. It ships in three parallel server APIs โ mod_php, CGI, and PHP-FPM โ and they behave differently under load, differently under misconfiguration, and differently under attack. A payload that dies against one SAPI can land clean against another. On top of that, PHP advertises itself. The X-Powered-By header has been leaking version fingerprints for two decades, and a meaningful share of production installs never turned it off.
That combination is why a host count can reach eight figures. The 22.6 million is not a measure of one product's defect. It is a measure of twenty-five years of configuration sediment.
Now the part that matters for anyone reading this with a crypto book open.
Most crypto front-ends are not PHP. They are static React bundles behind a CDN, and they are fine. The funnel around them is not fine. Landing pages. Referral and affiliate systems. Support portals. Regional marketing subdomains. Admin panels for campaign management. Token-claim and allowlist signup forms built by an agency on a five-hundred-dollar retainer and hosted on a cPanel box nobody has logged into since the last bull run.
During the 2022 unwind I spent three weeks on smart-contract audits for a portfolio I was already underwater on. Every hour went to bytecode. Not one hour went to the WordPress install that was collecting emails on the mint page. That install had an admin panel, a plugin stack with three abandoned dependencies, and valid TLS on a domain that carried our brand. I got lucky. Nobody exploited it. Luck is not a control.
So when a two-vulnerability advisory lands with 'exploited before disclosure' and no identifiers, I don't ask whether PHP is safe. I ask which of my funnel properties are running an EOL branch behind a panel I don't control.
The technical reality is a four-way intersection. A host is only exploitable if it satisfies all four conditions at once: it runs a vulnerable version; the vulnerable SAPI is actually reachable; the entry point is exposed to the internet; and no WAF or reverse proxy terminates the request before it reaches the interpreter.
The advisory addressed condition one. It said nothing about two, three, or four.
That gap is where the entire risk estimate collapses. 'Seventy percent of the internet' is a technology-stack penetration figure โ the kind of number W3Techs publishes โ and it has been quoted here as if it were an affected-population figure. The 22.6 million is a separate metric: scan-visible instances. Neither is an exploitable-surface count. Intersect the four conditions and the real number drops by roughly an order of magnitude.
That's not reassurance. Ten percent of 22.6 million is still 2.26 million hosts, and that is a lot of shells.
One more inference, flagged as inference. Two flaws, present for over a decade, exploited before disclosure, with massive exposure: the pattern most closely matches the CGI argument-injection family โ the 2024 class where a code-page conversion on Windows turns a query string into command-line arguments. I'm not asserting it. The advisory didn't give me the identifiers to assert anything. But if that's the shape, the affected population is Windows-plus-CGI โ narrow โ while the exposed population is everything else โ wide. Confusing the two is how you fund a nine-figure emergency response to a five-figure defect.
What the advisory also omitted is lifespan. It noted the flaws have existed for over a decade. That detail does more analytical work than the headline number, and nobody picked it up.
PHP's support cadence retires branches on a schedule. 8.1 leaves security support at the end of 2025. Behind it sits a long tail running 7.x and, in industrial quantities, 5.x. Those installs are not backlog. They will never be patched. Not slowly โ never. No maintainer, no patch contract, no upgrade path that doesn't break the CMS the business runs on. They are a permanent substrate, and permanent substrates become botnet real estate and backdoor hosting.
Which brings me to the layer the advisory barely touched: distribution.
The entity that actually ships a PHP patch to a long-tail host is not the PHP project. It is the hosting control panel โ cPanel, Plesk, the managed WordPress stack โ and in front of that, the CDN. A few dozen companies hold effective patching authority over the majority of the world's PHP surface. Most carry no explicit liability for it, and none capture the security upside when they ship the fix on time. The people who control distribution neither bear the risk nor book the return. That's not a market failure. That's an unclaimed arbitrage, and it has been sitting open for fifteen years.
The line item that actually costs money is detection.
The advisory quoted NCC warning that compromised systems may already carry backdoors. Take that seriously. The ratio of 'compromised but undetected' to 'confirmed compromised' in shared-hosting environments is brutal โ I'd put it above five to one on any estate I've scanned. Patching a host that already has a web shell doesn't remove the shell. You fix the door and leave the intruder in the hallway.
That's why the correct first action on an exposure list is not a package upgrade. It's retrospective compromise assessment: outbound connection baselines, unexpected cron entries, modified core files, new admin accounts, process trees spawning from the web user. Detection debt compounds. Patching debt doesn't.
For crypto specifically, the transmission path is worth stating plainly. Wallet drainers don't exploit the runtime โ they exploit people. But a backdoored admin panel on a regional marketing domain gives an attacker something a drainer can't buy: valid TLS, valid brand, and a mail server that passes SPF. That's the launchpad. The exploit is infrastructure. The payload is your user's seed phrase.
Here's the counter-intuitive read, and it's the one that pays.
Retail sees 'seventy percent of the internet at risk.' Smart money sees a free acquisition funnel for runtime-security vendors.
Look at the source structure. Every quantitative claim came from a commercial vendor. No independent researcher. No response from the project itself. No named victim. Two incompatible metrics โ a percentage and a host count โ placed in the same sentence so each makes the other look bigger. None of it peer-reviewed. None of it reproducible.
Those numbers are marketing assets, not research findings. They are engineered to travel. And they work: the more alarming the figure, the more syndication, the more free-scan signups, the more pipeline. The vendor's real product isn't the scanner. It's the moment of panic that gets a CISO to take the meeting.
I'm not calling it dishonest. I'm calling it a funnel, and funnels should be valued on conversion, not volume. If you're evaluating any of these companies โ public or private โ stop counting published advisories. Count research output to closed-won pipeline. That ratio is the business.
Pull back to a two-year horizon and the story changes shape. The real subject isn't the vulnerability. It's liability migration.
The EU Cyber Resilience Act entered into force in December 2024, with reporting obligations in September 2026 and full application in December 2027. Pure open-source projects sit outside it. Commercial integrators and managed hosts do not. The entity that packages PHP into a product will soon carry statutory responsibility for defects it did not write.
Set that against the governance side. The PHP Foundation was stood up in late 2021 with backing from Automattic, JetBrains, Zend, and Laravel. Its budget is a rounding error against the economic value flowing through the runtime it stewards. A foundation with a seven-figure budget is underwriting an eight-figure attack surface. That mismatch doesn't get solved by goodwill. It gets solved by regulators pushing cost onto whoever signs the invoice.
The trade is not 'PHP is broken.' PHP has been structurally broken for a decade and has outlived every prediction of its death. The trade is that patchability becomes a purchasable, verifiable property โ and the layer that sells it captures the margin.
Which is why I'd size this as a governance-cost hedge, not a catalyst. There is no clean listed pure-play, and the beta from a vulnerability advisory to any liquid security-infrastructure name is noise against a slow structural bid. The correct expression is a multi-year re-rating of runtime-exposure and software-supply-chain tooling.
And one more, from the collar I ran on a ten-million-dollar book in 2024: hope is not a hedge. Defining a downside doesn't feel like alpha. It just keeps you solvent long enough for the alpha to arrive.
What do you actually do this week.
Assume the long tail is already lost. Not 'at risk' โ lost. Stop budgeting for remediation of hosts that will never receive a patch, and start budgeting for isolation: egress filtering, virtual patching at the WAF or RASP layer, segmentation so a compromised marketing box can't reach a signing environment.
Run the four-filter triage before you run anything else. Version. SAPI. Exposed entry point. WAF termination. Whatever satisfies all four goes to the top of the queue. Everything else waits. Blanket emergency change windows are how teams burn a quarter and fix nothing.
If you run a crypto business, audit your funnel, not your contracts. Marketing subdomains, support portals, affiliate dashboards, campaign admin panels. That is where your brand is reachable and your bytecode isn't.
If you're a trader, read this for what it is: a governance-cost data point, not a price catalyst. The number to watch isn't 22.6 million. It's the ratio of hosts that get patched to hosts that get isolated.
Which leaves one question worth sitting with. If a defect costs nothing to disclose and nothing to leave unpatched, who exactly is paying for the fix โ and what are they charging you for it?