If your team parks a vulnerability because no one has shown a way to exploit it, PHP2Shell is the case against waiting. A PHP core developer found early signs of the bug in 2024, no one found a concrete exploit, and the fix stalled. This year, researchers working with frontier AI models turned it into unauthenticated remote code execution in PHP, the language runtime that serves a large share of the web. AI-assisted research has made finding and proving bugs cheaper for defenders and attackers alike, so the work that now decides your exposure is the fix: understanding the patch, getting it onto the versions you run, and shipping it before attackers use it.
Triage that waits for a proven exploit is waiting on a timeline that AI-assisted research sets, for defenders and attackers alike.
See how a parked 2024 finding became remote code execution
The PHP Foundation published its own account of how CVE-2026-109618 was found and fixed, and it reads like a triage decision most security teams would recognize. A 2024 external audit led a PHP core developer to the first signs of an out-of-memory problem. An exploit was theorized, but no one found a concrete attack vector. Every fix the security team considered came with a cost: a compatibility break, new denial-of-service potential, or changes to third-party extensions that seemed impossible to coordinate. With no known path to remote code execution, work on the fix stalled and restarted for months.
Then the research changed. Calif, auditing PHP through OpenAI's Patch the Planet program, reported an unconditional remote code execution with the same root cause. OpenAI reported the same root cause on its own, and Wiz added more attack paths. On Apache with mod_php, an unauthenticated request can trigger the bug before any application code runs. Both PHP2Shell CVEs are rated 9.2 under CVSS v4.0.
The PHP Foundation called the delay a structural failure of its own process and resources. The more useful lesson for your team is the shape of the failure: a known bug waited because exploitability was unproven, and AI-assisted research supplied the proof.
Expect AI-found bugs in the kernel, runtimes, and libraries you run
In April and May, Copy Fail, Dirty Frag, Fragnesia, and CIFSwitch hit the Linux kernel, and researchers have kept finding kernel vulnerabilities with AI since. Each of those four let an attacker who already had access to a system escalate privileges. PHP2Shell needs no access at all: the attack arrives over HTTP, against the runtime your web applications depend on.
The day the PHP fix shipped, Nathan Blackham, who leads the CIQ engineers who shipped those kernel fixes, wrote about AI-found CVEs that now include user-space software like PHP, in Patch PHP2Shell now and prepare for the next AI-found CVE. His expectation for what comes next: other language runtimes, and the libraries every distribution ships but few people read closely.
Read the CVE numbers for risk, then plan for the volume
Google's threat intelligence group put numbers on the trend in Vulnerability Discovery and Exploitation Trends in the AI Era. Monthly vulnerability disclosures rose from 5,045 in January 2026 to 10,740 in August. Exploitation in the wild rose from an average of 10.5 vulnerabilities a month in 2025 to 18 a month in 2026.
The same report warns against reading volume as risk. Vulnerabilities whose descriptions name the Linux kernel accounted for about 5,000 disclosures over those eight months, with no observed in-the-wild zero-day exploitation, and only about 0.23% of 2026 disclosures were seen exploited at all. The AI-discovered share points the other way: 50% of the vulnerabilities Google identified as likely AI-discovered lead to remote code execution, compared with 26% across the broader set.
When half of the vulnerabilities Google flagged as AI-discovered lead to remote code execution, sort your triage by consequence first and volume second.
From January to August 2026, Google recorded 141 vulnerabilities that were both disclosed and exploited, more than the 127 it recorded for all of 2025.
Check your PHP2Shell exposure. The PHP2Shell knowledge base article lists the patched packages by RLC Pro variant, the interim mitigations, and the update steps.
Retire "no known exploit" as a reason to wait
Does every low-severity finding become an emergency? No, and Google's exploitation figures show why: most disclosed vulnerabilities are never seen exploited. What changes is the reason you're allowed to park one.
Much of security triage still rests on the judgment that a bug is theoretical because no one can exploit it in practice. Google's report describes where AI models do their best work: memory corruption and logic bypasses in core C and C++ libraries, language runtimes, and hypervisors, found by reasoning through multistep code paths. Your production systems run that code whether or not your team maintains it.
A bug parked as too hard to exploit is now a candidate for the next AI-assisted audit, whether a defender or an attacker runs it.
For those components, rank a finding by what it would allow if someone proved the exploit, and by how exposed the affected systems are. Internet-facing PHP servers running mod_php sat at the top of that ranking for PHP2Shell.
Plan for the fix: read, backport, validate, ship
The PHP Foundation's post names the part AI doesn't do. "Tools now find bugs faster than ever, for defenders and attackers alike, and the number of reports will keep growing," the PHP Foundation wrote. "What tools cannot do is decide on the right fix for a long-standing design decision in the engine, weigh the compatibility trade-offs, and review the patch."
In Enterprise Linux, that work continues after upstream ships. The PHP project released fixes for its supported branches, PHP 8.2 through 8.5. Rocky Linux 9 ships PHP 8.0, and Rocky Linux 8 ships PHP as module streams, including 7.2, 7.4, and 8.0. For 7.4, 8.0, and 8.1, the project published source-only fix branches with no official binaries, so a distribution's engineers have to build, test, and ship those packages. PHP 7.2 got no upstream fix at all.
The same four steps repeat with every CVE: someone reads the upstream patch, backports it into the version in production, validates it, and ships it. For PHP2Shell, CIQ engineers shipped fixed base PHP 8.0 packages for Rocky Linux from CIQ Pro (RLC Pro) LTS 9.6 and 9.2 about three and a half hours after the upstream fix went public. Fixes for several module streams, and for CIQ Bridge on CentOS 7.9, followed over the next three days. A few older streams won't get a fix, including php:7.2, the default stream on Enterprise Linux 8.
Before the next AI-found CVE is disclosed, name the engineers who will read its patch, backport it to the versions you run, and validate it, and decide what they'll set aside to do it.
To connect with the experts who do this work every day, contact CIQ.
