AI Is Finding Old Bugs in PHP, Node.js and Linux. Your Patch Speed Is Now the Risk

On Wednesday 21 October 2026, the PHP project shipped 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical remote code execution bugs, CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2. The same day, Node.js shipped security releases for its 22, 24 and 26 lines. The most serious Node fix, a Brotli decoder flaw that can lead to remote code execution, is credited to OpenAI Codex Security. A week earlier, Tencent's Zhuque Lab published its write-up of "Vghost", a Linux kernel privilege-escalation bug that its multi-agent system, Corvus AI, found.

All three were found with AI help. I don't think the right reaction is to panic about AI. It is to accept that the cost of finding serious bugs in old, widely used code has dropped, and that the bottleneck has moved to you: how fast you can find out what you run and patch it.

What happened with PHP

According to the Wiz Research write-up, Wiz used its own agent together with Gemini and GPT models. It found the first PHP bug on 19 August, confirmed unauthenticated remote code execution against Drupal the next day and against WordPress the day after, and reported to the PHP security team on 24 August. Wiz says every PHP version released in the last decade is affected by at least one of the bugs, going back to 5.4. The PHP Foundation's own post says reports on the same root cause also came from Calif (11 August), working under OpenAI's Patch the Planet programme, and from OpenAI (18 September).

PHP's advisory says the risk applies to "all PHP installations serving web requests, including PHP-FPM, Apache with modphp, php-cgi, FrankenPHP and LiteSpeed". It rates the risk highest for modphp, where an unauthenticated request can trigger the attack "before any application code runs". That last part matters. Your WordPress plugins, your Laravel middleware and your web application firewall rules for SQL injection are not in the path. The bug is in the runtime underneath them.

PHP gave a day's notice. On 20 October it announced a critical release for 21 October at 14:00 UTC. The Foundation says the release was then brought forward from 22 October, after leaked CVE IDs circulated with a wrong CVSS score of 10.0. It also says Chainguard published fixed images at 07:41 UTC, more than six hours before the coordinated release time, breaking the embargo.

What followed is the part that should shape your planning. Cloudflare's CEO, Matthew Prince, told the Associated Press there had been "millions" of attempts to exploit the vulnerability after the announcement. The FBI's cyber division recommended taking websites offline if they could not be updated immediately. Government websites in Japan, the UK and Finland had parts offline or disrupted while they patched.

Why the AI part matters operationally

The interesting line in the Wiz write-up is not that AI found a bug. It is that the bugs had existed for over a decade, and that exploiting them meant chaining several bugs together, which Wiz describes as previously at the edge of what human researchers could practically achieve. Wiz says a single researcher did in about a week what would previously have taken a world-class team months. It also says language models helped adapt the exploit to different PHP versions, configurations and memory layouts.

Read that from the defender's side. The work that used to protect old code, the sheer effort of turning a subtle memory bug into a working exploit across many builds, is getting cheaper. The researchers in this case reported responsibly, but the same capability is available to people who won't.

The Linux case shows the same pattern. Tencent says Corvus AI pinpointed the Vghost defect in two hours. The bug comes from two commits made in 2017 and 2020, and affects kernels from 4.11 up to the 7.2 release candidates. The fix landed in mainline on 3 August, and the public write-up with working demonstrations followed on 12 October.

The volume is also rising. The PHP Foundation says its security team has published 15 CVEs since 1 July and has worked through more than 100 reports that were invalid, duplicates or could not be reproduced. Expect more advisories, for runtimes and libraries you have not thought about in years, and expect less time between "advisory published" and "exploit attempts everywhere".

The question to ask your team

When something like this lands, the useful question is not "are we vulnerable?" It is: "How many hours would it take us to patch every runtime we expose to the internet, and who decides to take a site offline if we can't?"

Many small and mid-sized teams keep application dependencies reasonably current, because tools such as Dependabot nag them. The runtime is a different story. It lives in a base Docker image someone picked in 2023, a managed hosting plan, a VM built by a contractor, or a shared host the marketing agency set up. PHP 8.1 and older no longer get updates from the PHP project, and PHP 8.2 reaches end of life on 31 December 2026. If you are on one of those, the fix may not exist for you as a simple update.

Picture a mid-sized hotel group. It has a WordPress marketing site, a PHP booking engine from a vendor, a Node-based guest app back end, and an ERP in the back office. On Wednesday afternoon the questions are: which of these run PHP, which version and SAPI, who hosts each one, whose phone number do we have, and who can say "take the booking engine down for an hour" without a meeting. If answering those takes until Friday, the advisory was not the problem.

A drill for this month

Run this as a tabletop exercise in a 90-minute session, then fix what it turns up.

List every internet-facing system and its runtime. For each one, record the language runtime and exact version (PHP, Node.js, Python, Ruby, .NET and so on), how PHP is served (mod_php, FPM, other), the base image or OS, and who hosts it. Include the marketing site, landing pages, vendor-hosted portals and anything an agency built.
Check this week's three items against that list.
- PHP: are you on 8.5.12, 8.4.27, 8.3.36, 8.2.35 or a distribution package with the fix backported? Anything on 8.1 or older needs an LTS vendor, a backport or an upgrade.
- Node.js: are you on 22.23.4, 24.22.1 or 26.12.1 or later? The Brotli bug affects code that decompresses untrusted input through node:zlib, so check where your services accept compressed uploads or requests.
- Linux: has your distribution shipped the Vghost fix? It matters most on hosts running KVM or untrusted local users, and in container hosts where /dev/vhost-net or /dev/vhost-vsock is exposed.
Time a runtime patch end to end. Pick one service and measure how long it takes from "new runtime version announced" to "running in production": rebuild the image, run tests, deploy. If you don't know the number, you don't have one.
Write the offline decision down. Name who can take a public site offline or put it behind a maintenance page, and under what condition. For this PHP release, the FBI's advice was to take sites offline if they could not be updated immediately. That is a business decision, and it should not be made for the first time at 3 p.m. on the day.
Know your mitigations in advance. PHP's advisory lists interim settings, such as lowering post_max_size and disabling session.upload_progress, and says they reduce exposure without making an installation safe. CDN and WAF vendors also published rules. Find out now whether you can push a php.ini change and restart workers fleet-wide, and whether your CDN plan includes managed rules.
Subscribe to advance notices. PHP announced this release a day early on php.net. Many teams only heard about it from the news. Put the project announcement feeds for your runtimes into a channel someone actually reads.
Plan your EOL exits. List anything on PHP 8.1 or older, PHP 8.2 (EOL 31 December 2026), or an unsupported Node.js line, and give each one a date and an owner.

What not to do

Don't buy an "AI security" product this week because of the headlines. Don't freeze all deployments either. The organisations that had the easiest Wednesday were the ones that could rebuild and redeploy quickly, not the ones with the most tools. The same AI tools that found these bugs are also being pointed at your dependencies by people who will report them responsibly, and by people who won't. Either way, the patches will keep coming, and faster.

Sources

Knowing which runtimes you expose, and how fast you can patch them, is exactly what a two-week discovery and audit sprint maps out; if that list doesn't exist yet, book a discovery call.