Why AI Has Made Exploit Prediction the Core Security Skill

12 min read
  • Governance & Risk
  • Workforce
  • Deep dive
Contents9 sections

The Six-Hour Head Start

On October 21, 2026, the PHP project shipped emergency fixes for two remote code execution flaws in the language runtime, recorded in the Common Vulnerabilities and Exposures (CVE) catalog as CVE-2026-109618 and CVE-2026-109619. Attack traffic probing for them had been observed more than six hours earlier, according to Black Kite, a vendor that sells supply chain risk assessment, citing public reporting of Cloudflare's observations. The flaws acquired a name, PHP2Shell, and the name moved faster than anything else about them.

By mid-afternoon the security industry was running an emergency. Zscaler ThreatLabz, the research arm of a security vendor, characterized the pair as critical unauthenticated remote code execution inside the core language runtime and urged every PHP user to update immediately. The Cybersecurity and Infrastructure Security Agency (CISA) published an alert the same day confirming the flaws reached essentially every common way PHP serves a web request. Because PHP sits underneath a large share of e-commerce, content management, and other web platforms, including Magento, Shopware, WooCommerce, WordPress, and Drupal, the advisory landed on nearly everyone at once.

A developer types on a worn keyboard in a dimly lit room, PHP source visible on the monitor under a desk lamp.

What most organizations could not do in those hours was answer a plainer question than whether to patch. They could not say with confidence where PHP was running inside their own estate, or which of those systems faced the internet. The alarm arrived faster than the inventory.

The Gap Between Alarm and Exploit

Within a day, the assessment softened. Sansec, an independent research firm tracking the disclosure closely, revised its own position: a PHP2Shell attack "needs specific knowledge of the target server and specific conditions on it," and so "mass exploitation is less likely than we first expected." A researcher testing the circulating proof-of-concept code found it did not work against a default PHP installation. Sansec's advice to e-commerce operators was to patch, and to leave their stores online while doing it.

CISA had been careful on the same point from the start. Its alert stated that "While CISA has not observed successful exploitation of these vulnerabilities in the wild as of the time of publication, they pose a risk to organizations if left unpatched." That is a precise sentence. It is not the sentence that traveled. The official severity rating itself recorded high attack complexity and additional conditions on exploitation. Black Kite reported that a pre-disclosure leak had circulated a perfect 10.0 before the official 9.2 was published, a claim its own post traces to an anonymous forum post with no supporting evidence. The larger number outran the correction.

Patching was still the right call. But the episode followed a familiar distribution. VulnCheck, a vulnerability intelligence vendor, found using its own exploited-vulnerability catalog that between 2014 and 2023 just 1.1 percent of published vulnerabilities were exploited in the wild, while 31 percent had a proof-of-concept available. An independent analyst summary of published exploitation data puts the overall rate in the same band, around 1.5 percent of published vulnerabilities, even as CVE volume has grown substantially. Public exploit code is common, but exploitation that works against a real, hardened environment stays rare.

Why the Window Keeps Shrinking

The case for reading the fine print is getting harder to act on, because there is less time in which to read it.

The UK National Cyber Security Centre (NCSC), assessing AI's effect on cyber threat through 2027, used its formal probabilistic language to state that AI-enabled tools will almost certainly improve threat actors' ability to exploit known vulnerabilities, and that the gap between disclosure and exploitation, already measured in days, will almost certainly narrow further. NCSC is deliberate about what kind of change this is, assessing that AI will "increase the volume and impact of cyber intrusions through evolution and enhancement of existing TTPs," meaning the tactics, techniques, and procedures adversaries already use, rather than new ones.

The mechanics are visible in the field. Google's Threat Intelligence Group reported observing the state-linked actor APT45 sending thousands of repetitive prompts that recursively analyze CVEs and validate proof-of-concept exploits, producing an arsenal Google assessed would be impractical to manage without AI assistance. Brandefense, a threat intelligence vendor, reports that the average interval between CVE publication and a working exploit is now measured in hours rather than weeks. That figure is commercial and should be read as directional, but it points the same way as NCSC's calibrated assessment and Google's observation of an actual adversary.

Most patch governance was designed with considerably more slack in it than today's disclosure-to-exploit timelines allow.

Defenders Get the Same Acceleration

A security analyst reviews vulnerability dashboards across three monitors in a daylit office.

The same capability is available to defense, and it shows up first in deciding what to work on. The Exploit Prediction Scoring System (EPSS), maintained by the Forum of Incident Response and Security Teams (FIRST), a nonprofit incident response body, is a data-driven model estimating the probability a given vulnerability will be exploited within the next 30 days, published daily and free for every CVE. FIRST is explicit that it produces a forecast rather than a record, estimating exploitation likelihood "based on vulnerability features and current threat signals, not on a lookup of confirmed past exploitation." For a team working a severity-sorted backlog, that reframing changes which ticket gets opened on Monday morning.

Inside security operations, the reported effect is throughput. The 2025 ISC2 Cybersecurity Workforce Study, a survey of more than 15,000 practitioners by a nonprofit certification body, found that 63 percent of teams working with AI security tools report a significant boost to productivity. That is self-reported sentiment, not instrumented measurement. Independent, methodologically transparent measurement of AI's effect on mean time to detect and respond remains thin, and most of what circulates comes from companies selling the tooling.

The limits travel with the capability. EPSS accuracy depends on the quality of its training data, and FIRST itself acknowledges that model performance decays over time and requires retraining. A model produces a probability. A person still has to decide what to do with it, and both attackers and defenders got faster at roughly the same moment.

When Automation Floods the Queue

What happens when volume outruns judgment is already documented, and open source reached that point first. Daniel Stenberg shut down the curl bug bounty program on January 31, 2026, after AI-generated submissions swamped it. The program had confirmed 87 vulnerabilities and paid out more than $100,000 over its life, with a confirmation rate above 15 percent for most of that run, before Stenberg wrote that "not even one in twenty" reports was real. The Open Source Security Foundation (OpenSSF) vulnerability disclosures working group has documented the same wave across other major projects, noting that validating these reports "can take significant time, consuming valuable volunteer time and resources." The submissions arrive confident, well-formatted, and plausible, which is what makes refuting them expensive.

Enterprise operations hit the same arithmetic from another direction. Torq, a vendor selling security automation, describes one Fortune 500 security operations center it worked with handling more than 15,000 alerts a day at roughly 85 percent false positives, with analysts spending upward of six hours per shift on triage alone, a figure not independently corroborated elsewhere. Those figures come from a company selling the remedy, though the pattern matches what maintainers report independently and without compensation.

Faster inputs without better filtering produce the same outcome in both settings: more effort spent in the wrong direction, spent more efficiently.

Three Moves Worth Making Now

Three practices determine how well an organization absorbs the next cycle. In our view, organizations that handle an episode like PHP2Shell without losing a week tend to have all three settled before the advisory lands. They are in the order a resource-constrained team can realistically take them on, not in order of importance.

Order the queue by exploitation, not severity. CISA publishes the Stakeholder-Specific Vulnerability Categorization decision tree, a free model designed to help government and critical infrastructure organizations decide what genuinely warrants emergency response. Paired with EPSS scores and CISA's known-exploited catalog, it turns a severity-ordered backlog into an exposure-ordered one. In the first week this is an agenda change more than a tooling project. Name an owner for the exploitation-intelligence feed, and rewrite the standing patch review so the opening question becomes what is being exploited against assets we expose, rather than what scored highest this month. The base rates make the case: if roughly one percent of published vulnerabilities are ever exploited, a severity-first queue spends most of a team's finite remediation capacity on things nobody will attack.

Be able to establish exposure in minutes. The first action CISA urged during the PHP episode was identifying and inventorying every system running any version of PHP across the organization. That instruction is only fast to follow if the inventory already exists. Greenlight Guru, which sells quality management software and has a commercial interest in software bill of materials (SBOM) adoption, describes the Log4Shell split plainly: teams without an inventory spent weeks on code archaeology, while teams holding one queried for the component and knew their status in minutes, an account not independently corroborated outside vendor sources. Palo Alto Networks, a security vendor, describes the same mechanism of pinpointing affected components the moment an update ships. The Cyentia Institute's independent research puts the scale of the underlying backlog at 70 percent of Windows assets and 40 percent of Linux and Unix systems carrying at least one open vulnerability with a known exploit available, which is the work an inventory is meant to help a team get through. PHP sharpened the point because the flaws sat in the engine, so major commerce and content platforms were affected even where their own code was clean. A maintained list of internet-facing systems and the runtimes beneath them, owned by a named person and reviewed quarterly, covers most of the value of a full SBOM program at a fraction of the effort, and it is what turns the exposure question into a query.

Settle the human checkpoint before the emergency. Decide in advance who holds authority to call a drop-everything patch cycle, and write down where a person must validate an automated or AI-generated finding before anyone acts on it. The National Institute of Standards and Technology (NIST) AI Risk Management Framework and its Generative AI Profile supply the governance scaffolding, built around incorporating trustworthiness considerations into how AI systems are designed, used, and evaluated. The operational rule is simpler and comes from Stenberg: never report a vulnerability you do not understand and cannot reproduce. Applied internally, nothing escalates to crisis footing until someone has demonstrated it against your own environment. Checkmarx, an application security vendor, frames the design question as deciding explicitly which calls an AI system makes on its own and which require human authorization.

A short tabletop exercise against the last urgent advisory an organization received tends to surface which of the three is weakest faster than any written assessment.

Judgment Is the Scarce Input

AI capability advances whether or not a given organization is ready for it. The binding constraint is the supply of people who can supervise it well. The ISC2 workforce study found AI to be the most pressing skills need among practitioners at 41 percent, ahead of cloud security at 36 percent, with risk assessment and governance close behind. Those are the capabilities that decide whether an advisory becomes a crisis or a Tuesday, and they are harder to hire for than tool operators.

That pairing is the work we do with clients at Spruce. Our AI practice helps commercial and public sector organizations connect AI-accelerated detection and triage to governance that holds up under scrutiny: exploitation-informed prioritization, dependency inventory that answers exposure questions quickly, and documented human review over automated findings. The frameworks referenced here are free and public. The effort is in wiring them into how a particular organization decides under time pressure.

Where to Start This Quarter

NCSC's assessment describes a trajectory rather than an event: more volume, greater impact, built on tradecraft that already exists. Close enough to plan against, far enough out to prepare for.

If a structured look would help, bring us your most recent urgent advisory response, your current patch cycle, or your open vulnerability backlog. We will work through three questions: whether prioritization reflects exploitation likelihood rather than severity alone, whether you can establish exposure in minutes, and whether a documented human checkpoint sits between an AI-generated finding and the action taken on it. One conversation is usually enough to see which needs attention first.

The clock will keep accelerating on both sides of this challenge. The organizations that hold up are the ones that use the quiet weeks between advisories to settle their prioritization, their inventory, and their escalation authority, before the next name starts traveling.

Sources

  1. Black Kite. "PHP2SHELL: Two Critical Remote Code Execution Vulnerabilities in the PHP Core." Black Kite, October 21, 2026
  2. Zscaler ThreatLabz. "CVE-2026-109618 and CVE-2026-109619: PHP Vulnerable to Unauthenticated RCE Attacks." Zscaler, October 21, 2026
  3. CISA. "Critical Vulnerabilities in PHP Require Immediate Patching." CISA Alerts, October 21, 2026
  4. Sansec. "PHP2Shell: PHP RCE (CVE-2026-109618, CVE-2026-109619)." Sansec, October 22, 2026
  5. VulnCheck. "State of Exploitation: A Peek into the Last Decade of Vulnerability Exploitation." VulnCheck Blog
  6. Srikanth RP. "Only 1.48% of CVEs have been exploited in the wild." LinkedIn
  7. National Cyber Security Centre (UK). "Impact of AI on cyber threat from now to 2027." NCSC, May 2025
  8. Google Cloud Threat Intelligence. "Adversaries Leverage AI for Vulnerability Exploitation, Augmented Operations, and Initial Access." Google Cloud Blog
  9. Brandefense. "Disclosure to Exploit: How Fast Are New CVEs Weaponized?" Brandefense Blog, April 2026
  10. FIRST. "Exploit Prediction Scoring System (EPSS) FAQ." FIRST, accessed October 2026
  11. ISC2. "2025 ISC2 Cybersecurity Workforce Study." ISC2, December 2025
  12. Attaxion. "What Is the Exploit Prediction Scoring System (EPSS)?" Attaxion Glossary, accessed October 2026
  13. StingRai. "Curl Killed Its Bug Bounty Over AI Slop: A Triage Playbook." StingRai Blog, July 23, 2026
  14. OpenSSF. "AI-SLOP: Develop best current practices for Open Source maintainers." OpenSSF GitHub Issue #178, accessed October 2026
  15. Torq. "Alert Fatigue in Cybersecurity: Overcoming Analyst Burnout." Torq Blog, accessed October 2026
  16. CISA. "Stakeholder-Specific Vulnerability Categorization (SSVC) Guide." CISA Publications, accessed October 2026
  17. Greenlight Guru. "Software Bill of Materials (SBOM) for Medical Devices: What FDA Expects in 2026." Greenlight Guru Blog, accessed October 2026
  18. Palo Alto Networks. "What Is a Software Bill of Materials (SBOM)?" Palo Alto Networks Cyberpedia, accessed October 2026
  19. Cyentia Institute. "Prioritization to Prediction, Vol. 5." Cyentia Institute, accessed October 2026
  20. NIST. "Artificial Intelligence Risk Management Framework: Generative AI Profile." NIST AI 600-1, July 26, 2024
  21. Checkmarx. "Human in the Loop Cybersecurity: Designing HITL Controls for AI and AppSec." Checkmarx, accessed October 2026

Want our take on your AI roadmap?

We help leaders turn strategy into production AI systems. Let's talk about what you're building.