Six months ago, I wrote that vulnerabilities were going to come in waves. I undersold it.
In April and May, Copy Fail, Dirty Frag, Fragnesia and CIFSwitch hit the Linux kernel. Researchers have kept finding kernel vulnerabilities with AI ever since. I predicted waves, each built around a different class of bug. What came was a steady cadence that hasn’t let up in six months. My kernel team has met every one of them, patching and shipping fixes in the kernels we release. Each CVE sharpened how we triage, backport and validate. Today’s response shows the result.
The two CVEs released today in PHP take this pattern from the kernel into user space. We’ve handled other AI-assisted CVEs, including remote ones. None of them came close to the scale or threat of PHP2Shell.
The kernel bugs required an attacker already on the system. PHP2Shell is unauthenticated remote code execution in the runtime under most of the web. It’s the clearest evidence yet that AI-assisted CVE discovery now reaches every layer of the stack.
Today, October 21, the PHP project shipped fixes for two vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 under CVSS v4.0, and both sit in the PHP language itself, so every application built on it inherits the exposure. The attack arrives over HTTP. Against Apache with mod_php, it works before any application code runs. Wiz, one of the groups that reported the bugs, says PHP powers 70% of the websites in the world and that every version back to 5.4 is affected.
The response was severe before anyone saw the details. Reuters reported that an EU agency warned websites might need to go offline while PHP prepared its patches. Many EU governments took affected sites offline, and attacks appeared before the patches were published.
How these bugs were found is what should concern every infrastructure leader. The bug behind CVE-2026-109618 was old. PHP’s own 2024 security audit surfaced the first signs of it. Nobody found a concrete way to exploit it, and without a proven path to remote code execution, the fix stalled. This summer, three separate groups got there on their own. Calif, auditing PHP through OpenAI’s Patch the Planet program, and OpenAI itself both reported it on August 11. Wiz followed on August 24 with more attack paths. In Wiz’s words, proving these bugs were exploitable “required an exceptionally complex chain of steps, at the edge of what human researchers could practically achieve. Frontier AI models substantially reduced that barrier, turning a longstanding flaw into an exploit.”
With AI, the researchers took a known problem, one that sat partly because nobody could show it was exploitable, and turned it into remote code execution across a large share of the internet. When three groups land on the same bugs within two weeks, others were almost certainly looking too. Details leaked ahead of the coordinated release, and Cloudflare has already reported attackers reshaping their payloads to get around its protections.
Yesterday, October 20, the PHP project announced a critical release for today. The announcement gave only the severity, and that was enough to set the media conversation in motion. We didn’t wait for details. We staffed up ahead of disclosure, so our engineers were ready to start the moment the fix landed. It went public just before 14:00 UTC on Wednesday. Within the hour, fixes were in review for RLC Pro LTS 9.6 and 9.2. We released both about three and a half hours after the upstream fix went public. Fixes for our other distros are rolling out now. We also work closely with the Rocky Linux community so that customers running Rocky Linux are protected.
That speed is no accident. It comes from six months of handling increasingly complex CVEs against production code, and from refining our process with every one. Our engineers read an upstream patch under pressure, judge where it touches code paths customers depend on, backport it into versions upstream has moved past, and validate it before it reaches a production system. Plenty of enterprise teams prefer to self-serve, and that model works best with expert engineers behind every update. When the threat is unauthenticated RCE across most of the web, that expertise decides whether production workloads stay protected within hours or stay exposed for days.
As with the kernel over the last six months, I don’t expect PHP2Shell to be the last critical user space CVE found with AI. If you run PHP, patch these two now. Then make sure you have the process and the engineering depth to patch the next CVE just as fast, because your business and your infrastructure depend on it.
I expect the pace to keep climbing. Last month, Google’s threat intelligence team reported that monthly CVE disclosures doubled this year. Half of the vulnerabilities it believes were found with AI lead to remote code execution, compared to about a quarter of the rest. The PHP Foundation put it plainly in its own write-up: “Tools now find bugs faster than ever, for defenders and attackers alike, and the number of reports will keep growing.”
That changes which bugs matter. Much of security triage still rests on “that one is theoretical, nobody can exploit it in practice.” PHP2Shell shows what happens when that assumption breaks. Every bug parked because it looked too hard to exploit is now a candidate, and these models are getting very good at the long, complicated exploit chains that used to keep those bugs safe. The kernel came first this year because it’s high-value and heavily studied. PHP came next because it’s everywhere. Next comes the long tail: other language runtimes, and the libraries every distribution ships but very few people read closely.
Finding bugs is getting cheaper. Fixing them at the same speed takes engineering depth. Someone still has to understand the patch, backport it to the versions running in production, test it and ship it. In Enterprise Linux, that’s usually a version upstream has already stopped supporting. Every AI-assisted disclosure adds to that work, and teams that only face it occasionally will struggle to keep up. Our engineers do it every day, and every CVE makes them faster and more precise on the next one. That’s the work production environments depend on now, and it’s what our team is built to do.
Six months ago I said the waves were coming. They became a steady stream that has moved past kernel space and now reaches the software that runs most of the web. Our team is ready for whatever comes next.
Check out our PHP2Shell KB article for current patch status, interim mitigations and update steps for each variant. To see how RLC Pro can protect your production workloads before the next critical CVE arrives, talk to our team.
