On Wednesday, people in the Netherlands who tried to check their tax records or apply for government benefits found the doors locked. DigiD, the login system Dutch residents use for public services, went offline. So did MijnOverheid, the government’s online mailbox, and the website of the House of Representatives.
No one had broken in. The government pulled the sites itself, as a precaution, while technicians raced to fix a weakness in software that sits underneath a large share of the internet.
The Netherlands was not alone in choosing caution. “These weren’t all organizations that had been compromised,” said Garrett Calpouzos, a researcher at the software security company Sonatype. “Many deliberately took services offline because they couldn’t confidently rule out exposure or safely patch them fast enough.”
Related: Patched isn’t the same as protected. Here’s how to tell the difference. The PHP2Shell Checklist: You’re Not Safe Until You’re Safe
The flaws, which security researchers have nicknamed PHP2Shell, came to light on Tuesday and were patched on Wednesday. Over the following 48 hours, they set off a worldwide scramble involving government agencies, technology companies and the people who keep millions of websites running. They also exposed how hard it is to fix a problem buried deep inside the web, even after a fix exists.
What is PHP, and What Went Wrong?
PHP is a programming language created in the mid-1990s to build web pages. Most people never see it, but it does the work behind the scenes when a website loads a page, takes a login or processes a form. WordPress, the software behind a huge number of blogs, news sites and small-business pages, runs on it. So does the software that powers Wikipedia.
The cybersecurity company Wiz estimates PHP runs about 70 percent of websites. That figure measures how widely PHP is used, not how many sites are vulnerable, but it explains why the alarm spread so quickly.
The two flaws sit in PHP itself, not in any particular website. They involve how PHP manages a computer’s memory as it handles requests from visitors. Under the right conditions, an attacker could send a specially crafted request to a website and end up running their own commands on the server behind it, with no password needed. Security professionals call that remote code execution. In practical terms, it can mean stealing data, defacing a site or using it as a foothold to reach other systems.
The flaws had been in PHP for more than a decade, affecting versions back to 2012. They were found this summer by researchers using artificial intelligence. A security firm called Calif found the first one in August while using an OpenAI model, during a review OpenAI paid for. Researchers at Wiz, which Google owns, found both flaws independently weeks later, also with help from AI tools.
A Carefully Planned Release that Came Apart
When researchers find a serious flaw, the industry usually follows a quiet routine. The researchers tell the software’s maintainers privately. The maintainers build a fix and share it in confidence with a small circle of companies that distribute the software, so they can prepare updates. Everyone agrees to stay silent until a set date. That agreement is called an embargo. The goal is for the fix and the news to arrive at the same moment, so attackers don’t learn about the weakness before defenders can close it.
This time the routine broke down. On Tuesday afternoon, the identifying numbers for the two flaws began circulating online, though PHP’s maintainers say no technical details leaked at that point. Hours later, Calif mistakenly posted a video of its proof-of-concept attack, according to the PHP Foundation, the nonprofit that supports the language. PHP moved its release up by a day, to Wednesday.
The foundation has also accused Chainguard, a software security company that had received the fix in advance, of “unilaterally” breaking the embargo by publishing updated software more than six hours before the official release. Anyone could then have studied the fix to work backward to the flaw. Chainguard’s chief executive, Dan Lorenc, does not dispute the timing but told The Register the company leaked nothing. He said it acted because attacks were already underway.
Jason Baker, who leads threat intelligence at GuidePoint Security, said the riskiest part of any embargo is the gap between when a fix is ready and when it is released. “That’s the stretch where the largest number of people hold both the bug and the patch,” he said. Keeping that window as short as possible, he said, reduces the chance of leaks, intentional or not.
Someone was clearly probing early. Amazon said its network of decoy servers, set up to attract attackers, recorded an attempt to exploit the flaws on Oct. 17, four days before the fix came out. It is not known who was behind it or how they learned of the flaws.
Has Anyone Actually Been Hacked?
Not that anyone has confirmed. Attack code began circulating online on Wednesday, and security companies saw a flood of attempts. But the code mostly doesn’t work.
Baker said his team had seen no attempts that led to a break-in. Many used flawed code that he described as “AI slop.” Matt Hull of NCC Group, a British security firm, said his investigators had found no confirmed backdoors, the hidden entry points attackers leave behind.
Marcus Hutchins, a researcher at the security firm Expel who became known in 2017 for helping stop the WannaCry ransomware outbreak, wrote on LinkedIn that the broken code had been a lucky break. Because it “didn’t really work, but people believed it did,” he wrote, it “just barely bought everyone enough time” for the patch to come out.
That cushion may be thin. VulnCheck, a security research company, says it has built an attack that does work against common server setups, though it has not released it publicly. Shane Fry, chief technology officer of RunSafe Security, said his team got past a standard built-in protection within an hour.
That is why Hull urges organizations to look backward as well as forward. “Organizations should not mistake patching for proof that their systems are clean,” he said. A server that was exposed before the fix may already have been tampered with.
Why a Patch isn’t the End of the Story
For a phone, a security fix means tapping “update” and restarting. For the web, it is messier, for three reasons.
Installing a fix doesn’t always switch it on. Web servers run continuously, and the old software can keep running after the new version is installed. Researchers at the security company Echo installed the patched PHP on a test server without restarting it. Visitors’ requests were still handled by the old, vulnerable version. “Installing a patch doesn’t necessarily mean the patched code is actually running,” said Yuval Saggie, an Echo researcher. It is like installing new locks but leaving the old door on its hinges.
“The clock stops when the fix is running in production,” said Eylam Milner, Echo’s chief technology officer, meaning when the updated software is actually serving the public.
Many organizations don’t know where PHP is running. It is built into products that companies buy for other reasons, including the control panels of firewalls and other network equipment. Palo Alto Networks, a major maker of corporate firewalls, said all versions of its firewall software are affected, and its fixes are not ready yet. Cisco is still checking 18 products and 13 online services. Customers cannot fix those themselves; they must wait for the manufacturer.
“Companies know they own the product but not that PHP runs inside it, so it never makes the patch list,” said Jim Sherlock of ProCircular, a security consulting firm. Justin Beals, chief executive of Strike Graph, which helps companies meet security standards, said many businesses take stock of their software only once a year. “That cadence passes an audit,” he said, “and tells you nothing during a week like this one.”
Older versions will never get an official fix. Like many software projects, PHP stops supporting old versions after a few years. Yet more than 1.1 million internet-facing servers still run versions that no longer get updates, according to VulnCheck. PHP’s maintainers published partial fixes for a few of them, but those require technical skill to install, and the oldest versions get nothing. For those servers, the realistic options are to upgrade the software, hide the server from the public internet, or turn it off. Taking sites down temporarily, as the Dutch government did, is the same logic applied while the fixes go in.
Sherlock put the trade-off bluntly. “A day of downtime costs far less than a break-in.”
What it Means for You
The flaws affect the computers that host websites, not personal phones or laptops. There is nothing for an ordinary internet user to install.
The risk to individuals is indirect. If an attacker took over a website you use, they could get at the information stored there, such as account details, or tamper with the site itself. As with any security incident, it is a good moment to use unique passwords and turn on two-step login where it is offered.
The bigger burden falls on small businesses, nonprofits and anyone else who runs a website, often without a technical staff. Sherlock said companies that use a managed hosting service may already be covered; his own firm’s site was patched automatically by its host. Others should ask whoever runs their site, whether a web host, an agency or a freelancer, three things, according to Echo: Has the fix been applied to both flaws? Has the server been restarted? And has someone checked that the fixed version is actually running?
A Preview of What AI May Bring
The episode is an early look at a shift security experts have been predicting. AI tools are making it faster and cheaper to find hidden flaws in old software, for defenders and attackers alike. Wiz called the PHP discovery an “AI inflection point.”
“Flaws we once thought were impractical to exploit are back on the table,” said Ramy Rahman, an engineer at the security company ArmorCode. Baker of GuidePoint noted that these flaws were found in August and fixed in late October. “It’s hard to imagine,” he said, that such a timeline will hold “as bugs become easier and cheaper to find.”
That speed puts new strain on the people who maintain the software. PHP is kept up largely by a small team supported by a nonprofit foundation. In July, the foundation said AI tools had driven a marked increase in security reports, some of them invalid, that its small team must still check one by one.
Hutchins of Expel wrote that PHP’s long record of few serious bugs probably reflected how few researchers were looking, not how safe the code was. He said he would be surprised if this were not “just the first wave of an absolute tsunami of critical PHP vulnerabilities.”
Andrew Obadiaru, chief information security officer at Cobalt, a security testing company, said organizations should use this week to prepare for the next one. That means knowing what software they run, who is responsible for each system and who can take it offline in an emergency.
“The next advisory will arrive with less warning than this one,” he said.
