How to stay secure when AI finds vulnerabilities faster

On October 21, 2026, the PHP project shipped fixes for two remote code execution flaws now called PHP2Shell. One of them was first noticed by a PHP core developer in a 2024 audit and left alone because nobody could show it was exploitable. In August 2026, researchers using frontier AI models showed that it was. The CVE IDs leaked on October 20, the PHP project moved the release up a day, exploitation appeared in honeypots the day the fix went public, and every PHP version from 5.4 on was affected, including versions upstream stopped maintaining years ago.

Events like this change what a Linux security program has to be good at. This guide answers three questions: what AI-assisted vulnerability discovery is doing to the volume and shape of CVEs, what it takes to get updates out faster, and how organizations stay secure when fixes have to reach every version they run. It uses PHP2Shell as the worked example; our PHP2Shell patching guide covers the specific commands.

What AI-assisted discovery changed

The Google Threat Intelligence Group published its analysis of the trend on September 30, 2026. The headline numbers:

Measure	Value	Period
Vulnerabilities disclosed per month	5,045 to 10,740	January to August 2026
High risk disclosures per month	131 to 350, up 167 percent	January to August 2026
Distinct vulnerabilities exploited in the wild	141, against 127 in all of 2025	January to August 2026
AI-discovered vulnerabilities that result in remote code execution	50 percent, against 26 percent ecosystem wide	January to August 2026

GTIG is careful about the first row. Automated CVE assignment policies in open source ecosystems inflate raw counts; descriptions containing "Linux kernel" alone generated about 5,000 CVEs in those eight months, none of them observed as exploited zero-days. Volume is not the whole story. The rows underneath it are: more high risk findings, more exploitation, and a discovery pipeline that disproportionately produces the worst class of bug.

The mechanism is visible in PHP2Shell. Finding a memory corruption bug has been within reach of fuzzers and auditors for years. Proving that a particular bug yields code execution, with a working chain, is what turns a finding from "known, low priority" into "critical, patch now," and it is the step AI models have made cheaper. In Wiz's words, proving these bugs 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." Researchers at the security firm Calif reported the remote code execution path on August 11 through OpenAI's Patch the Planet program, OpenAI reported the same root cause independently, and Wiz followed with further attack paths. Every mature code base has a backlog of findings that were parked for the same reason the PHP one was. Expect the backlog to come due.

A second effect follows: once a fix is public, the patch itself is a guide to the bug. GTIG suggests attackers may be using AI tools to compare patches and versions and turn known vulnerabilities into working exploits faster, and for PHP2Shell, watchTowr observed exploitation in its honeypots on October 21, the day the fix was released.

What getting updates out faster takes

"Patch faster" sounds like a policy decision. It is a pipeline, and each stage has a cost someone pays in engineering time.

1. Read the upstream fix. A distribution engineer has to understand what changed and why, often from a patch with little commentary because the advisory is under embargo. For PHP2Shell, CIQ engineers staffed up ahead of disclosure and started the moment the fix went public, just before 14:00 UTC on October 21.

2. Backport it to every version you ship. This is the expensive step. Upstream released fixed binaries for PHP 8.2 and later. Enterprise Linux 9 ships PHP 8.0 as its base package, Enterprise Linux 8 ships 7.2, 7.4, and 8.0 as module streams, and CentOS 7 ships 5.4. For 7.4 and 8.0, the PHP project published source-only fix branches, and distribution engineers had to build, package, and test them. For 7.2 and 5.4, no upstream fix exists at all. A backport means finding the equivalent code in a version where the surrounding code has changed, rewriting the fix for it, and confirming it does not alter behavior applications depend on. The 5.4 fix for CentOS 7 exists because CIQ Bridge engineers did that work.

3. Build, test, sign, publish. Each version, each architecture, each stream is a separate build. A fix that breaks php-fpm on restart is worse than no fix, so the build has to pass tests before it is signed and pushed to the repository.

4. Tell people. An advisory, a knowledge base article with the exact package versions, and interim mitigations for hosts that cannot update today. The CIQ article for PHP2Shell went up on October 21 with the first fixed packages.

For Rocky Linux from CIQ Pro (RLC Pro) LTS 9.6 and 9.2, the four stages took about three and a half hours from the upstream release. RLC Pro 8, 9, and 10 followed on October 22, and RLC Pro LTS 8.6 and CIQ Bridge on October 23. Each stage has to be someone's daily job, staffed before the CVE arrives, because none of it can be learned during the incident.

Then the fix has to reach your hosts, which is a second pipeline you own:

• Inventory. You cannot patch what you cannot find. The hard case in PHP2Shell was Enterprise Linux 8 hosts running the default php:7.2 module stream, for which no fix exists anywhere. A fleet report of dnf module list --enabled php is the difference between knowing that on day one and finding out from an incident.
• Rollout. Updating a package and restarting its workers on a thousand hosts is an automation job. An Ascender Pro job template that runs the update, restarts php-fpm or httpd, and records the resulting package version gives you both the rollout and the evidence.
• Images. Containers and stateless nodes are not patched in place. They are rebuilt from a fixed base and redeployed. Warewulf Pro cluster nodes boot from a node image, so patching the image and rebooting puts every node in a known fixed state.
• Measurement. Record the time from upstream release to the last patched host. That elapsed time is your real exposure, and it is the number the next PHP2Shell will test.

How organizations stay secure

Six decisions, made before the next CVE, shorten that window.

Know which versions you run, down to the stream

Vulnerability scanners that key on the upstream version number can misread distribution backports in both directions: they can flag a fixed 8.0.30 build as vulnerable and miss a 7.2 stream that has no fix. Keep an inventory keyed on the package version the distribution ships, and know which streams have a maintainer.

Pin production to a long-term support release that someone is patching

An old version is only a liability if nobody is fixing it. A pinned long-term support release with active security engineering is the safest place to be during an event like this, because the fix arrives as a package update that does not change the version your applications were tested against. RLC Pro LTS releases get up to four years of security patching on even-numbered minor versions, and PHP2Shell showed what that looks like in practice: the pinned 9.6 and 9.2 streams were the first to be fixed.

Treat mitigations as a bridge, never the destination

The PHP advisory offered configuration changes that close specific attack paths, and said plainly that none of them makes an installation safe. Apply them to hosts you cannot patch today, record where you applied them, and remove them when the patch is in, unless the vendor says to keep one. PHP did exactly that on October 23: it asked everyone to keep session.upload_progress.enabled = 0 until the next regular bugfix release, because that setting also blocks an unlikely RCE path that will get its own advisory as CVE-2026-115560. A mitigation that becomes permanent is an unpatched host with a false sense of safety, and a mitigation removed before the vendor says so is the opposite mistake.

Rebuild images on a schedule, not only in emergencies

A container image or node image built last quarter carries last quarter's PHP. A team that already rebuilds images from a current base on a schedule can handle a CVE like PHP2Shell by bumping the base tag and running the pipeline. A team that rebuilds only when forced has to find every image first.

Add detection for the window you cannot close

There is always a gap between a fix going public and your last host being patched, and attackers now work inside that gap. Runtime detection gives you a signal during it. RLC Pro Hardened ships Linux Kernel Runtime Guard, which detects kernel tampering, privilege escalation, and rootkit behavior in progress on the running system. It detects exploitation attempts; it does not prevent them and it does not replace patching. It works as a sensor for the hours you are exposed, and it can feed a SIEM or log platform you already run.

Put someone on the hook for versions upstream has abandoned

CentOS 7 reached end of life in June 2024. PHP 5.4 on those hosts had no upstream fix at all. If you run software past its upstream life, either migrate it or contract for CVE remediation on it with an explicit scope. CIQ Bridge delivers backported Critical and Important/High severity fixes across a curated set of priority packages on CentOS 7.9, through the Bridge repository and Depot Client, while the migration to RLC Pro or RLC Pro Hardened is planned. The runway matters because it ends in a destination.

Have engineers whose job is CVE response, in house or through a partner

Everything above depends on people who read upstream patches, backport them, build them, and publish them, every day and not only during incidents. That is the work CIQ engineers do for RLC Pro customers, so the customer's engineers stay on their roadmap.

Where CIQ fits

CIQ handles the operating system part of this strategy. Each product maps to a stage above.

Need	What CIQ provides
Fixes for the versions you run, fast	RLC Pro and RLC Pro LTS: backported security fixes on pinned minor releases, with up to four years of security patching on even-numbered minors. PHP2Shell fixes for RLC Pro LTS 9.6 and 9.2 shipped about three and a half hours after the upstream release.
Detection during the exposure window	RLC Pro Hardened ships Linux Kernel Runtime Guard (LKRG), which detects exploitation attempts. It does not prevent them and it does not replace patching.
Fixes for CentOS 7 while you migrate	CIQ Bridge: CVE remediation for CentOS 7.9 across a curated priority package set, including the PHP 5.4 backport for PHP2Shell.
Rollout and evidence across the estate	Ascender Pro: job templates that update packages, restart services, and record the result, with role-based access control. Ascender Ledger, included with Ascender Pro, records automation-driven change.
Known state for cluster nodes	Warewulf Pro: stateless nodes booted from a patched image, so every node is in a known state after every boot.
Someone to call	Enterprise support: a one-hour Severity 1 first response during business hours on Standard, and 30 minutes, 24x7, on Premium.

What CIQ does not do is make the problem disappear. No vendor can promise an estate is fully patched or free of exposure. What a partner can do is take the stages that need specialists off your team's plate, ship them quickly, and show you the package versions to prove it.

FAQs

Is AI really finding more vulnerabilities, or just more reports?

Both, and the distinction matters. The Google Threat Intelligence Group counted monthly disclosures doubling from 5,045 in January 2026 to 10,740 in August, but warns that automated CVE assignment inflates raw counts, with about 5,000 Linux kernel CVEs in that period and no observed in the wild zero-day exploitation among them. The signal underneath is that high risk disclosures grew 167 percent in the same window and that half of AI-discovered vulnerabilities result in remote code execution, against 26 percent across the wider CVE ecosystem.

What does it take to ship Linux security fixes faster?

Shorten each stage between an upstream fix and a patched fleet. Have engineers who read the upstream patch, backport it to every version you run, build and test it, and publish it as their daily work. Keep an inventory that knows which version and stream every host runs. Pin production to a long-term support release so a fix is a package update rather than a migration. Use an automation platform that can update and restart services across the estate in one run. Measure the elapsed time and treat it as a service level.

What is a backport and why does it take engineers?

A backport applies a fix written for the newest release to an older version still running in production, often one upstream no longer supports. The code around the bug has usually changed, so the patch rarely applies cleanly. Someone has to understand the fix, find the equivalent code in the old version, rewrite the change, build it, and test that it fixes the bug without changing behavior applications depend on. For PHP2Shell, upstream shipped binaries only for 8.2 and later and source-only fixes for 7.4, 8.0, and 8.1. Distribution engineers built and tested the 7.4 and 8.0 packages from those fixes, and CIQ engineers backported the fix to PHP 5.4 for CentOS 7, which no upstream branch covers.

Should we stop using long-term support releases because old versions are targets?

No. The target is the version, not the support model. A long-term support stream with active security engineering gets fixes as package updates while the version stays the same, which is faster and safer than an emergency version upgrade. The risk is a pinned version that nobody is patching. RLC Pro LTS releases get up to four years of security patching on even-numbered minor versions, and a PHP2Shell fix for RLC Pro LTS 9.6 shipped about three and a half hours after the upstream release.

Does runtime protection replace patching?

No. Linux Kernel Runtime Guard, which RLC Pro Hardened ships, detects kernel tampering and exploitation attempts already in progress. It does not prevent them and it does not replace patching. Its value is the window between disclosure and patch, when it gives you a signal that something is being exploited rather than silence.

What do we do about systems upstream no longer supports, like CentOS 7?

Either migrate them or put someone on the hook for backporting fixes to them. CIQ Bridge is CVE remediation for CentOS 7.9: backported Critical and Important/High severity fixes across a curated set of priority packages, delivered through the Bridge repository with Depot Client, while the migration to RLC Pro or RLC Pro Hardened is planned and executed. The PHP 5.4 fix for PHP2Shell shipped through it on October 23, 2026.

How does CIQ fit into a security strategy?

CIQ does the operating system work that takes engineers: reading upstream fixes, backporting them to the RLC Pro and RLC Pro LTS versions customers run, building and publishing them, and shipping fixes for CentOS 7.9 through CIQ Bridge. Ascender Pro rolls the updates out, Warewulf Pro rebuilds stateless cluster nodes from a patched image, and RLC Pro Hardened adds runtime detection. Your team keeps its roadmap while the CVE work happens as someone else's daily job.

Sources

• Google Threat Intelligence Group, Vulnerability discovery and exploitation trends in the AI era, September 30, 2026.
• PHP project, October 21, 2026 security releases, and advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp.
• PHP project, Informational advisory: Session upload progress, October 23, 2026, on keeping session.upload_progress.enabled = 0 until the next regular bugfix release.
• CIQ, Mitigating CVE-2026-109618 and CVE-2026-109619 (PHP2Shell) on Rocky Linux 8, 9, 10, and LTS variants.
• watchTowr, PHP2Shell FAQ, on in the wild exploitation.
• The PHP Foundation, Today's PHP security release, and how we're strengthening PHP security, October 21, 2026, on the 2024 audit finding, the discovery, and the release timeline.