On October 21, the FBI, NSA, and cybersecurity agencies in the United States, Europe, and the United Kingdom all said the same thing: If you can't patch your website immediately, take it offline. That is not a routine recommendation. It ought to interrupt the usual conversation about putting more of our lives online.
PHP needed urgent fixes because an attacker could potentially use it to run their own instructions on a website’s hosting computer. They wouldn’t necessarily need an account. Researchers had demonstrated an attack that could begin before the site’s own software started doing its job.
PHP helps run WordPress and a huge number of other websites. W3Techs put its use at about 69 percent of sites whose underlying programming language it could identify. That measures how widespread PHP is, not how many websites somebody broke into. Still, this was an emergency involving software that businesses all over the world rely on.
WordPress users couldn’t solve this by installing a WordPress update. The project’s warning explained why:
These vulnerabilities are not specific to WordPress and affect any server that hosts a PHP application. No WordPress update is required or planned for these issues. Versions of PHP prior to 8.2 no longer receive security updates from the PHP project. If your site runs a version prior to this and you manage your own web hosting, you should consider taking your server offline while you prepare to update to a newer version of PHP.
For affected systems that could not be protected promptly, disconnecting was something to consider. I can think of few recommendations less welcome to somebody trying to sell things online. Customers cannot place an order, but neither can an attacker reach the disconnected service. By Wednesday, attackers were already trying. Cloudflare's chief technical officer wrote that the company was seeing early attacks emerge. Patchstack, a cybersecurity platform, reported active exploitation as well.
The PHP Foundation’s account makes uncomfortable reading.
The warning signs for one problem went back to 2024. A developer spotted them, but researchers had not found a practical way to carry out an attack. Proposed repairs could break other software. Progress repeatedly stalled while the team struggled to agree on an approach, and developers with the necessary expertise had competing responsibilities. The foundation acknowledged:
"We won't pretend otherwise: the delay was a structural failure, caused by both the security team's decision process and its lack of resources."
The foundation says it is changing how it handles these decisions. I'd want to see that followed through. It describes moving away from a process that required consensus, allowing decisions by majority and encouraging compromises. That addresses something more specific than a promise to try harder.
The release did not go smoothly even once a fix was ready. According to the PHP Foundation, Chainguard, a company that develops open-source software meant to reduce cybersecurity vulnerabilities, shared details of the patch six hours before its scheduled release, breaking an embargo agreement. Posting that information early made it easier for attackers to reverse-engineer the fix and keep exploiting the vulnerable software. Institutional dysfunction, meet institutional carelessness.
Calif, a security company, used OpenAI's GPT-5.6 Sol to identify a critical flaw, according to OpenAI. Wiz independently discovered and reported both vulnerabilities. The job of producing the repairs fell to PHP's maintainers.
Here’s a use for AI I can appreciate without much hesitation. Find the hole before somebody uses it against us. Yet the impressive discovery still ends at an engineer’s desk, where somebody must work out a repair that customers can install. Faster discoveries make that person’s availability more important.
Other developers had updates waiting that Wednesday, too. Node.js, which runs online applications, fixed a problem that could allow an attacker to give their own instructions to an affected computer.
Developers using GitLab to manage their software projects also had a warning to deal with. A flaw rated 10 out of 10 for severity could allow someone without a login to run code on an affected server. Every version going back to 7.0, 12 years of releases, was affected. GitLab had already updated its own website; customers running the software themselves needed to install a fix.
Nothing here establishes a coordinated attack. These were separate defects. But for anyone maintaining several affected systems, finishing the PHP update would hardly be cause to call it a day. There were other computers to check and other repairs waiting.
Our recent coverage of hacked supermarket refrigeration in France supplied a particularly ugly example of the costs. Some affected equipment had outdated software or no longer received security support. Employees got the cleanup, and stores lost inventory.
Paying the people who maintain a foundation of your business seems like an ordinary business expense. It should not take an emergency recommendation to unplug the website to make the case.
