PHP bug found by AI: what the 70% claim means

An AI-assisted security review uncovered critical vulnerabilities in PHP, the server-side scripting language that runs a large share of the web, and patches were released under emergency pressure in 2026. The widely repeated claim that 70% of websites were at risk describes the installed base of PHP, not a count of sites confirmed as vulnerable, and site owners should treat patching as the priority.

What the PHP bug found by AI actually was

The PHP bug found by AI was a long-dormant weakness, first introduced into the language more than 20 years ago, that researchers turned into a working exploit in the summer of 2026 using AI models from OpenAI, the company behind ChatGPT and the GPT model family. Existing behavior had been noticed before, but nobody had published a practical attack.

That distinction matters for anyone reading the coverage. A bug that crashes a process and a bug that lets an attacker run their own code are different problems. The 2026 work closed that gap, which is why the disclosure escalated from an interesting edge case into an emergency patch cycle.

PHP is an open-source server-side scripting language used to generate web pages. It sits underneath content management systems including WordPress, and it appears inside a long tail of custom applications, internal tools and government sites that were written years ago and have not been revisited since.

Why the 70% of websites figure needs context

The 70% figure describes PHP's share of websites, not the share of sites confirmed to be exploitable. Coverage of the disclosure, including the CBS News interview with Wall Street Journal reporter Robert McMillan, framed the number as exposure, and that reading is defensible only as a measure of how much of the web depends on PHP.

Actual risk depended on configuration, on whether the affected code path was reachable, and on how quickly each host applied the vendor fixes. A site counts toward the 70% simply by running PHP somewhere in its stack. It does not follow that every one of those sites could be attacked.

The wider lesson is about inventory. PHP is often installed as a dependency by a hosting provider or bundled into a framework, so an operator may be running it without having chosen it. That is exactly the situation where a patch lag lasts longest, because nobody is watching the changelog.

How AI changed the exploit research timeline

AI compressed the research phase of the disclosure. McMillan described the vulnerability as something that would have consumed months of tedious human effort, and said the researchers' own assessment was that a model could work through that kind of long, repetitive task faster than a person.

That is a statement about research throughput, not about autonomous hacking. The models were pointed at a specific topic area by people who already knew roughly where to look. The value came from grinding through variations at a pace that made a hard problem tractable.

Two consequences follow for defenders. First, the window between a promising research lead and a working exploit is shorter than it used to be. Second, any public hint about where a vulnerability lives now carries more risk, because the effort to reconstruct an exploit from a hint has dropped. McMillan said researchers involved in the disclosure were explicit that leaking early could have produced a no-patch window with exploit code already circulating.

The leak, the rushed patch, and the NSA warning

News of the vulnerability leaked before the coordinated release, and the PHP project moved its patch publication forward by a day. McMillan reported that Amazon later confirmed exploit code had been written before the patches became available, which is the scenario everyone coordinating the disclosure had been trying to prevent.

The National Security Agency issued guidance telling organizations running PHP to update immediately and, where that was not possible, to take affected systems offline until mitigation was complete. That recommendation is unusually blunt, and it reflects how central the language is to public-facing infrastructure.

Response varied. McMillan described European government sites going offline and the image board 4chan suspending comments. Some operators pulled the plug and protected themselves. Others, he suggested, likely did not know they were running PHP at all.

What site owners should verify now

Confirm which PHP version each site runs, and confirm it against the current security release rather than against whatever the control panel reports. Then apply the vendor patch and re-check that the running process actually restarted with the new binaries. A patch applied to a package that a supervisor never reloaded leaves the old code live.

Use this as a working order of operations:

1. Inventory every PHP installation, including staging environments, internal tools and forgotten subdomains.
2. Check the installed version against the current release notes on php.net.
3. Apply updates, then restart the PHP-FPM or Apache module process so the new code loads.
4. Review web server logs for exploit attempts against the affected endpoints during the disclosure window.
5. Document which installs are owned by third parties and get written confirmation of their patch status.

The inventory step is the one most likely to be skipped and the one that matters most. A patched production site next to an unpatched staging copy that shares a database is not a mitigated site.

A second point about process discipline: emergency patching is a rehearsal of the incident response plan, not a substitute for one. If your organization discovered during the 2026 disclosure that nobody knew who owned a particular installation, that gap will show up again on the next advisory.

Why a small team carries so much web infrastructure

The PHP project is volunteer-run, with a small number of employees, and the coordination burden during the disclosure fell on that group. McMillan quoted one contributor saying that writing software for fun is not the same job as coordinating patches across an ecosystem.

That mismatch is a structural feature of open-source infrastructure, not a one-off. A language embedded in a large share of the web is maintained by people who may hold other jobs, and the disclosure window compresses months of coordination into days.

For teams building on PHP, the practical takeaway is to track the project's release channels directly rather than waiting for a downstream host to relay the news. Following the PHP release announcements puts you a hop closer to the source.

How AI is shaping attack and defense

AI assistance now affects both sides of the patch race, and the 2026 PHP disclosure is a clear example of the defensive use case. Researchers used models to find code paths that human reviewers had circled without resolving. The same capability is available to anyone who knows where to aim it.

Security teams are already applying similar tooling to their own codebases, though results depend heavily on how much context the model receives and how the findings are validated. A model that flags a suspicious pattern still needs a human to confirm whether the code path is reachable in production.

For developers, this shifts some value from knowing syntax toward understanding what the code actually does at the boundary. The tools that read code are improving. The judgment about which findings matter still comes from the person reading them.

Where tools like Crazystack TypeScript and Dev doido fit

Modern application stacks reduce the share of legacy code running unreviewed, which is the practical argument for typed, tooling-heavy setups. Crazystack TypeScript refers to TypeScript-based scaffolding from the Brazilian developer tooling project Crazystack, which generates typed application starters rather than leaving developers to assemble a stack by hand.

Dev doido is the developer content channel that covers this kind of tooling for a Portuguese-speaking audience, and the pattern it represents matters here: type systems, generated scaffolds and consistent project structure make dependency versions visible. A visible version is a patchable version.

That is not a claim that typed stacks avoid vulnerabilities. It is a narrower point. The teams that suffered most during the 2026 disclosure were the ones that could not say which PHP version a site was running. Tooling that makes dependency state explicit shortens that conversation.

Frequently asked questions about the PHP vulnerability

• Did AI find the PHP bug on its own? No. Researchers pointed current OpenAI models at a specific problem area inside PHP that humans had already identified as suspicious. The models accelerated the search for a working exploit; the direction came from people.

• Does the 70% of websites figure mean 70% of sites were hacked? No. The number reflects PHP's share of websites, as reported in coverage of the disclosure. Confirmed exploitation depended on configuration, reachability and patch timing.

• What should I do first if I run a PHP site? Apply the current PHP security release and restart the PHP process so the new binaries load. Then verify that staging, internal and forgotten installs are on the same patched version.

• Why did the patches ship a day early? Information about the vulnerability leaked before the coordinated release date. The PHP project moved publication forward to shorten the window in which exploit code could circulate without a fix available.

• Is PHP still safe to use for new projects? PHP remains widely deployed and actively maintained. The incident exposed a maintenance coordination problem across a volunteer-run project, not a reason to abandon the language. Keep versions current and watch release announcements.

• What did the NSA actually recommend? The agency advised organizations running PHP to update immediately and to take systems offline where updating was not possible until mitigation was complete.

• Could this happen again in another language? The pattern, long-dormant code plus AI-accelerated research, is not specific to PHP. Any widely deployed runtime with old edge cases is a candidate for the same kind of scrutiny.

Turning recorded expertise into written guidance

A disclosure like this one produces a lot of talking: interviews, conference talks, internal postmortems, streamed walkthroughs of what went wrong and how the patch was coordinated. Most of that knowledge stays inside a video file, where search engines cannot index it and future teammates will not find it.

That is the gap Skala Blog is built for. Paste a YouTube URL, let the tool transcribe the video, and generate a structured article from the transcript, then edit it into something accurate enough to publish. The patches shipped in days. The explanation of what happened deserves to outlast the recording.

Skala Blog

Source video