AI 協助研究人員在 PHP 中發現兩個潛伏十多年的嚴重漏洞

PHP released emergency security updates today for two critical vulnerabilities that allow an attacker to run code on a web server without logging in. The flaws, nicknamed PHP2Shell, are tracked as CVE-2026-109618 and CVE-2026-109619, and both carry a CVSS v4 score of 9.2. They affect the PHP engine itself, which means they sit underneath WordPress, Drupal, Magento, and every other site PHP serves, no matter how careful the code on top is.

PHP2Shell: AI found critical PHP flaws · NotVibesCoded

Two critical remote code execution flaws sat in PHP, the language behind roughly 70% of websites, for more than a decade. AI models helped researchers find…

notvibescoded.com

The detail that should get your attention is not the severity score. It is how the bugs were found, and how quickly they were turned into working attacks once someone looked properly.

What PHP2Shell Actually Is

Both flaws are memory-safety bugs in how PHP handles requests, and both end in unauthenticated remote code execution.

• CVE-2026-109618 corrupts memory during out-of-memory handling. When a request runs out of memory mid-setup, PHP's error recovery can leave request data half-initialised, and the cleanup path then treats that broken data as valid.
• CVE-2026-109619 is a use-after-free problem with global state. Data from one visitor's request can outlive its memory and be picked up by a later request. One confirmed attack route runs through PHP's session upload-progress feature, which has been enabled by default for over a decade.

Every PHP installation that serves web requests is in scope: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The PHP team rates mod_php as the highest risk because a demonstrated exploit fires from a single unauthenticated request before any application code runs. Login screens and security plugins never get a chance to help.

Wiz, the Google-owned security company that independently found both bugs, says every PHP release back to 5.4 is hit by at least one of them. The flaws have effectively been sitting in the codebase for more than a decade.

How AI Found Them

In August, Ryan Austin, a researcher at the security firm Calif, was auditing PHP's source code with help from GPT-5.6 Sol, one of OpenAI's most advanced models. The audit was part of Patch the Planet, an open-source security programme OpenAI launched in June with Trail of Bits. Austin found one of the flaws. Wiz's researchers, working independently with Google's Gemini 4 Argon, GPT-5.6 Sol, and their own research system, found both.

OpenAI has published its account of the response under the title "Patch the Planet", and calls the bugs "one of the most impactful security issues in recent memory". That is not just marketing. The class of bug involved had been flagged as a problem area decades ago and then largely forgotten, because exploiting it was considered too difficult. AI changed the economics of trying. By the researchers' account, the models helped turn a theoretical weakness into reliable exploitation with as few as a few dozen requests to a server: seconds on small systems, hours on complex ones. Work that would have taken a skilled team months took about a week.

Calif's chief executive, Thai Duong, put the other half of the problem plainly to the Wall Street Journal: "Some dude on Twitter could take the patches and run AI against it and post some exploit script. All hell will break loose." Once a patch ships, anyone can diff it against the old code and ask a model to explain exactly what changed and where the bug was. The same capability that found the flaw can reverse-engineer it.

The Scramble

The coordinated disclosure did not survive contact with the internet. Details of both CVEs circulated on Hacker News and social media on October 20, a day before the planned announcement, and an exploit demonstration dubbed php2shell spread online. PHP pulled its release forward by a day.

On the morning of October 21, Cloudflare's CTO reported early attacks already in progress, roughly six hours before the patches landed, and said the company had deployed emergency firewall rules for all customers, including free ones. He was explicit that this was a stopgap and that only patching solves it. CISA and the FBI urged organisations to patch immediately. In the Netherlands, the national login system DigiD, the parliament website, and the country's own cybersecurity agency took their sites offline as a precaution. Security telemetry counted more than 22.6 million internet-exposed servers running potentially vulnerable PHP.

The fixes shipped at about 13:35 UTC in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.

If You Run PHP, Patch Now

The PHP Foundation's position is blunt: "There are no complete mitigations, updating is the only safe choice."

• Update to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Linux distribution and LTS users should check their vendor for packages, which were shared in advance.
• Do not rely on workarounds. Setting session.upload_progress.enabled=0 blocks one confirmed attack path for CVE-2026-109619 and nothing else.
• PHP 8.1 and older get no upstream fix. The PHP team released minimal source backports for 7.4, 8.0, and 8.1, and some vendors are backporting further, but an unpatched legacy install that cannot be updated should be taken offline until it can be. A large share of the PHP servers visible on the internet still run unsupported versions, and they are now the softest targets on the web.

The Part That Matters After Today

Strip away the incident response and one fact remains: flaws that survived a decade of human review were found and weaponised in weeks once frontier models were pointed at the code. That cuts in both directions at once. Defenders get an auditor that never gets tired and can read an entire engine looking for one bad assumption. Attackers get the same auditor, plus a patch-diffing machine the moment a fix ships.

This time the defenders moved first, and the coordination worked: researchers, maintainers, hosting providers, and governments had fixes and firewall rules ready before a working exploit was public. OpenAI is explicitly proposing that kind of coordinated response as the model for what comes next, because the discovery side is only going to get faster.

For anyone building software with AI, including the AI-assisted kind covered on this site, the lesson is uncomfortable and useful. The review bar just moved. Code that merely looks right has always been a liability; now there is machinery that can systematically find the places where it is not right, whether you run that machinery on your own code first or someone else runs it for you. Shipping fast is fine. Shipping unreviewed is becoming a measurable risk with a timeline attached.

Originally published on NotVibesCoded, where the PHP2Shell piece covers what happened, how AI found the flaws, and what to patch. Read the full article there, and follow for honest, hands-on coverage of building with AI.