AI helped find a hole in PHP, but patching old servers is still a job for humans

On Wednesday, October 21, the PHP developers released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, announced a day earlier without details. They fix two vulnerabilities known together as PHP2Shell, both rated 9.2 out of 10 on the CVSS scale. They're most dangerous on Apache servers with mod_php: there, an attacker can run their own code without logging in, using nothing but HTTP requests, before the website executes a single line. Other ways of running PHP aren't safe either, including the popular PHP-FPM. PHP powers about 69% of websites whose server-side language can be identified, including Wikipedia and sites built on WordPress, The Verge reports, citing W3Techs. We covered the discovery on Wednesday.

The oldest vulnerable code dates back to PHP 5.4, released in 2012. The underlying bug in out-of-memory handling was spotted back in 2024, while fixing issues found in an external audit. But nobody showed how to exploit it, so PHP's security team, which was short on people, kept putting off the fix - the PHP Foundation calls it a "structural failure." In August of this year, Calif and OpenAI independently reported the bug, followed two weeks later by Wiz, which is owned by Google.

Wiz says it used the Gemini 4 Argon and GPT-5.6 Sol models along with its own Wiz Atlas tool. According to the company, "With frontier AI models and the right tools, a single researcher completed in a week what previously would have taken a world-class team months of work." Only OpenAI has said which model helped Calif. Calif was hunting for bugs as part of Patch the Planet, a program run by OpenAI, and it was OpenAI that announced the flaw had been found with GPT-5.6 Sol. Calif itself doesn't name the model, saying only that it used models available to everyone.

AI is also speeding up attackers. CJ Moses, Amazon's chief information security officer, explains that in the past most exploitation started only after a working exploit had been published. According to Moses, AI now makes it cheap to build a working exploit from just the patch or the security advisory. That means more attackers can strike within hours or even minutes of the details going public. Matthew Prince, CEO of Cloudflare, said that Cloudflare saw tens of thousands of exploit attempts across its network in the 45 minutes after the patch was released, and millions less than 12 hours later.

Some attackers didn't even wait for the patch. According to the PHP Foundation, the vulnerability IDs leaked online the day before the release, and Calif mistakenly posted a video of a working attack for a short time. Cloudflare recorded thousands of attempts in the 10 hours before the patch was released. Amazon found an even earlier attempt in its data, from October 17, before the leak. Nobody knows how anyone knew about the flaw that early. No successful break-in has been confirmed so far, though.

Some institutions chose not to wait. As CNBC reports, citing Reuters, the Netherlands took down sites including the government portal Overheid.nl, the Port of Rotterdam's website and even the website of the NCSC, the country's own cybersecurity center. In Finland, the state IT provider Valtori disconnected public government services from the internet, and France took local government websites offline. CERT Polska, Poland's national CERT, recommended the same even before the patch came out: temporarily shutting down internet-facing services running PHP, as long as that wouldn't disrupt the organization's work. CISA advises taking offline any systems that can't be updated right away, as well as everything running PHP 8.1 or older.

Some administrators have already upgraded old systems with AI's help and are describing it on forums. One Reddit user writes, "It just took me 30mins with Claude to upgrade a complex LMS system from 5.6 to 8.5." An administrator of hundreds of Drupal 7 sites says that without AI these upgrades would have taken months, and that Claude Code now fixes the errors that appear after switching PHP versions. Another administrator describes spending two hours with an agent scanning their systems and planning the update. Then they asked it to build a summary dashboard and went to lunch. On Hacker News, someone wrote that Claude turned their MediaWiki blog into static pages, so the blog can run without PHP until the server is patched. These are only the authors' own accounts, and nobody has verified them.

But these are stories of people who knew what they were doing and could move to a new version without rushing. Anyone who has to rescue a production server in a hurry today has it much harder, and there are plenty of those servers. Recorded Future cites VirusTotal scans: servers at about 1.1 million IP addresses reveal their PHP version, and 758,000 of them, nearly 70%, run PHP 8.1 or older. The PHP team no longer supports those versions and hasn't shipped a ready-made release with the fix for them. CISA advises taking such servers offline until they're updated.

That leaves fixes from Linux distributions and hosting control panels, but not everyone will get one. According to a roundup by Digital Applied, Amazon has no plans at all to patch some PHP packages in Amazon Linux. Ubuntu 20.04 got the fix only in Ubuntu Pro, which is free on no more than five machines. So Laravel Forge advises replacing any server running Ubuntu 20.04 or older with a new one and shutting the old one down.

Without a ready-made package, all that's left are source code fixes the PHP team published for versions 7.4, 8.0 and 8.1. You have to apply them yourself and compile PHP, with the same extensions as before. Older versions didn't even get that. One Reddit user has a site on PHP 5.6, so they had Claude port the fixes to that version. And they immediately admitted: "Is it usable? Who the hell knows."

Even after updating, it's hard to tell whether a server is safe. The version number from php -v doesn't settle it: in the Digital Applied roundup, 21 of 76 entries are packages that got the fix but kept the old version number. Ubuntu 24.04, for example, still shows 8.3.6 after the update. OpenAI's server-checking tool also warns that an "UNKNOWN" result doesn't mean "patched." Installing the fix isn't the end of it, either. You have to restart all PHP-FPM processes, because the ones started before the update keep running the old, vulnerable code. On servers with cPanel or Plesk, every installed PHP version has to be patched separately.

Quick workarounds come at a price. Blocking multipart requests, which Sansec among others recommends, cuts off file uploads, and in some stores, as the company itself acknowledges, it breaks the shopping cart too. Removing the memory limit (memory_limit=-1) sidesteps the out-of-memory bug, but then a single request can eat up all of the server's memory. And the PHP team warns that no setting fully protects you.

AI let people down, too. According to Hostinger customers, the company's chatbot insisted that PHP-FPM wasn't vulnerable, even though the PHP developers say plainly that it is. On Hacker News, several users complained that the safety filters in Claude and Codex interrupted their work on the vulnerability.

A simple divide emerges from these accounts. AI greatly speeds up the work of someone who knows how PHP runs on their server, where the packages come from and what to check after an update. Someone who doesn't know that will still get a ready-made plan, but won't be able to judge whether it's any good.

A site owner who doesn't run the server themselves can start with two questions for whoever does: is the fix installed yet, and has anyone gone through the logs since October 17, when Amazon recorded the first exploit attempt? If nobody can answer, one Hacker News commenter suggests considering managed hosting, where the provider keeps PHP up to date.

Glossary: CVSS - a 0-to-10 scale used to rate how serious a security vulnerability is. Exploit - a program or sequence of requests that takes advantage of a vulnerability in practice. mod_php - PHP running as a module of the Apache web server. PHP-FPM - PHP running as a separate pool of processes that the web server hands requests to. Multipart - the HTTP request format browsers use to submit forms with files.