The Verge's warning is unusually blunt: a critical vulnerability in PHP, the language that renders a large share of the public web, may take websites down today. Whether the damage arrives through exploitation or through a rushed patch, the sentence captures something structural about PHP that no amount of code review fixes. The ecosystem patches slowly, and when it does patch, it patches all at once.
PHP is not one product. It is a family of runtimes: the build your Linux distribution ships, the build your hosting panel pins, the build inside a container image assembled two years ago, and the one bundled with a plugin's "easy installer." W3Techs has long placed PHP on roughly three-quarters of websites whose server-side language can be identified, and WordPress alone accounts for a large fraction of all sites on the internet. When a flaw lands in the runtime, the blast radius is not a product's install base. It is the web's default stack.
The asymmetry is familiar and still brutal. An attacker needs one reachable instance and one working exploit. A defender needs every instance patched, every virtual-machine image rebuilt, and every customer on a shared host covered by somebody else's maintenance window. Mass scanning typically begins within hours of a proof of concept going public, and the gap between advisory and internet-wide probing has been shrinking for a decade.
The operational advice is unglamorous, and it is the only advice that works. Inventory what actually runs PHP and at which version. Stage the update against the real application, not a hello-world. Patch. Where you cannot patch immediately, put a compensating control in front of the exposure: a WAF rule, a virtual patch, a disabled feature. Watch error rates during the rollout, because a bad interaction with an extension can take a site down just as effectively as an exploit. And if you rely on managed hosting, ask the provider directly whether you are covered and when. "We handle updates" is not the same answer as "you are on the patched build."
There is a longer lesson buried in the auto-update machinery. The same mechanism that lets a hosting company patch millions of sites in an afternoon is the mechanism that would let a compromised update do the same. PHP's long-tail problem is not a shortage of patches. It is a shortage of anyone who knows what is installed, on which version, behind which plugin, for which customer. That inventory gap is what turns a routine advisory into a bad week.
Disclosure specifics — affected versions, the precise trigger, the mitigations the maintainers recommend — belong in the advisory rather than in a summary, and should be read there before anyone acts. What can be said without qualification is that the clock started when the warning went out, and the sites that come through this cleanly will be the ones that already knew what they were running.
