Security teams are drowning in alerts they already knew how to triage. They are not drowning in the alerts that matter. OX Security’s 2026 analysis of 216 million security findings across 250 organizations, collected over 90 days, found that raw alert volume grew 52 percent year-over-year. That number sounds alarming. The number that should actually alarm security leaders is 400 percent: the growth in prioritized critical risk over the same period. The ratio of critical findings to raw alerts nearly tripled, from 0.035 percent to 0.092 percent. More alerts than last year. Disproportionately more high-impact alerts within that total.
OX Security observed a direct correlation between that density increase and AI coding tool adoption. Organizations with higher AI tool usage in their development workflows showed the most pronounced growth in critical vulnerability density. The alerts are not getting worse randomly. They are getting worse in a specific way, in specific places, for a structural reason.
This analysis synthesizes the OX Security report with two other data points from this week: the LMDeploy CVE-2026-33626 exploitation in 12 hours and the Bitwarden CLI supply chain attack. Together, they describe something more specific than “AI creates security risks.” They describe a structural shift in how software is built and deployed that has broken the traditional model of how security teams prioritize and remediate vulnerabilities.
The Traditional Prioritization Model and Why AI Broke It
The standard enterprise security workflow for the past decade has been: scan infrastructure and code for vulnerabilities, score them using CVSS, rank by severity score, remediate high and critical findings first, ignore or defer medium and low findings until capacity allows. This model assumes that CVSS severity is the primary signal for business impact. It was never a perfect assumption, but it was workable when the volume of findings was manageable and the distribution of severity reflected actual deployment risk reasonably well.
AI coding tools disrupt both assumptions. OX Security’s data shows that technical severity scores are no longer the primary driver of what makes a finding critical from a business perspective. The most common elevation factors, the properties that push a finding from raw alert to prioritized critical risk, are High Business Priority at 27.76 percent of elevated findings and PII Processing at 22.08 percent. CVSS High severity, the traditional filter, is a contributing factor but not the dominant one.
The practical implication: a medium-CVSS vulnerability in a new AI-generated microservice that handles payment processing is more dangerous than a high-CVSS vulnerability in a legacy internal tool that has not been accessible from the internet in three years. The medium-CVSS finding ranks lower under traditional triage. It represents higher actual risk. Security teams using CVSS-first workflows are systematically deprioritizing the vulnerabilities that matter most in AI-augmented development environments.
This is not just a scoring problem. It is a deployment topology problem. AI coding tools do not just generate code that contains vulnerabilities. They generate code that gets deployed as new services, new infrastructure, and new integrations, often faster than the organizational processes that would review those deployments for security properties. The code ships. The infrastructure runs. The security team learns about it later, often through a scan that finds the vulnerability, sometimes through an incident.
The Velocity Gap: Attackers Already Know About This
The OX Security report describes a “velocity gap”: critical vulnerability density scaling faster than remediation workflows. That framing is accurate but understates the asymmetry. The gap is not just between the rate of vulnerability creation and the rate of remediation. It is between the rate at which defenders can process new findings and the rate at which attackers can act on disclosed vulnerabilities.
The Sysdig Threat Research Team’s analysis of CVE-2026-33626 provides the concrete measurement. LMDeploy, an AI inference framework with 7,798 GitHub stars, had a critical SSRF vulnerability exploited in 12 hours and 31 minutes after the advisory was published. No proof of concept existed. The attacker read the advisory, understood the exploit primitive, and began scanning within half a day. Sysdig describes this as a pattern recurring across AI-infrastructure tools over the past six months.
The velocity gap, measured precisely, is 12 hours. That is the window between the publication of a vulnerability in a niche AI infrastructure tool and the first active exploitation in the wild. Enterprise patch cadences operate on days and weeks. The 400 percent growth in critical risk density is not just a measure of how many vulnerabilities exist. It is a measure of how many vulnerabilities exist in infrastructure that attackers are monitoring and ready to exploit before defenders can act.
There are two components to this gap. Attackers are moving faster. Defenders are also moving slower relative to their own infrastructure, because they do not know what they are running. The same organizations that have adopted AI coding tools have also deployed AI inference frameworks, agent orchestration tools, MCP servers, and RAG retrieval pipelines at a pace that outstrips security review. The OX Security finding that critical density is correlated with AI tool adoption is not a coincidence. It reflects the fact that AI tools generate infrastructure that gets deployed without the security properties that the organizations building with them require.
Where AI Coding Tools Generate Risk
AI coding tools generate risk in three specific patterns that the OX Security data and the week’s incidents illuminate.
Infrastructure deployed outside traditional security review. When a developer uses Claude Code, Cursor, or Copilot to scaffold a new microservice or API endpoint, that service often ships without the security review process that the organization would apply to manually-written code. The process gap exists because AI-generated code is produced much faster than the review cycle was designed to handle. A developer can scaffold, test, and deploy a new endpoint in hours. The security review queue is measured in days or weeks. The service ships without the review. This is the deployment topology change that the OX Security data reflects: more new code, deployed faster, with less security review coverage per deployment.
New dependency categories with unknown security properties. AI coding tools frequently suggest adding dependencies and library integrations that the developer may not have used before. Those suggestions reflect the model’s training data, not a current assessment of the dependency’s security posture. A developer building with AI assistance might add an AI inference framework, an MCP server library, or a RAG retrieval component based on a code suggestion, without being aware that the framework has a CVE filed against it or that the MCP library has documented security gaps. The Bitwarden CLI compromise this week is an example of a trusted tool with 250,000 monthly downloads being compromised and redistributed through the package manager ecosystem. AI coding tool suggestions that point developers toward recently-compromised packages are a vector that existing security tooling does not handle well.
AI infrastructure deployed as operational tooling. The expansion of AI-specific infrastructure, inference servers, embedding pipelines, model gateways, agent orchestration frameworks, and MCP server ecosystems, creates a new category of operational attack surface. This infrastructure carries IAM credentials, handles sensitive user data, and runs with broad network access. It is also, systematically, deployed outside the security review processes that govern conventional application infrastructure. LMDeploy running on a GPU instance with S3 access to model training data is not an edge case. It describes the operational reality of AI teams at organizations of all sizes.
The CVSS Problem Is a Where Problem, Not a What Problem
OX Security’s finding that the most common elevation factors for critical risk are High Business Priority (27.76 percent) and PII Processing (22.08 percent), with technical severity scores playing a secondary role, maps directly to the infrastructure topology change AI coding tools are driving. The shift in what makes a vulnerability critical is a shift in where vulnerable code runs.
An SSRF vulnerability in a web scraper has a CVSS score based on its technical characteristics. The same SSRF vulnerability in an AI inference server running on a GPU instance with broad IAM permissions to S3 model artifact buckets has a different real-world impact, but the same CVSS score. The CVSS model does not know the difference. It scores the vulnerability based on the class of flaw, not the context in which the flaw exists.
Traditional enterprise security organizations compensate for this through asset criticality scoring: the security team maintains a registry of which systems are high-business-priority or PII-processing, and applies elevated prioritization to vulnerabilities in those systems regardless of CVSS score. This compensation mechanism breaks down when the asset registry cannot keep pace with deployment velocity. If AI coding tools are deploying new services faster than the asset registry can register them, the compensation fails. New services with high business priority or PII processing properties ship without the elevated scrutiny that the security team would apply if they knew the service existed.
The 400 percent growth in critical risk density relative to 52 percent growth in raw alert volume is a measurement of this registry lag. The alerts are not growing as fast as the findings, because the security team cannot generate alerts for infrastructure it does not know exists. The critical findings are growing faster, because the infrastructure that AI tools deploy tends to be business-critical by nature. Payment processing integrations, user data pipelines, authentication flows, and AI services handling sensitive data are exactly the high-priority deployments that AI coding tools accelerate.
The Supply Chain Attack Surface Compounds Everything
The OX Security velocity gap exists inside organizations. The Bitwarden CLI attack this week illustrated that the same velocity dynamics operate at the supply chain level, with additional adversarial amplification.
The Bitwarden CLI compromise was live for 93 minutes. In that window, automated CI/CD pipelines installed the malicious package, executed the preinstall hook, and began exfiltrating credentials. The attack did not require any action from the developer beyond having a pipeline that installed npm packages. That is a standard CI/CD configuration. The 93-minute window interacted with automated build processes at a pace that human security operations could not match.
This is the supply chain component of the velocity gap. Attackers compromising developer tool distribution channels can reach automated build systems that operate continuously, without human review, and install packages at machine speed. An organization with 100 CI/CD pipelines that run overnight may have installed the malicious package 100 times in 93 minutes, across services that the security team has not reviewed and may not have in their asset registry.
The OX Security finding that critical risk density is correlated with AI tool adoption includes this supply chain exposure. AI coding environments integrate more tooling. More tooling means more supply chain touchpoints. More supply chain touchpoints means more exposure to campaigns like the TeamPCP attack pattern that has now hit Aqua Security Trivy, Checkmarx, and Bitwarden in a single month. The critical vulnerability density in AI-heavy development environments is not just a code quality problem. It is a supply chain surface area problem.
What the Data Says About Where This Is Going
The OX Security report is a 90-day snapshot from the first quarter of 2026. It captures a trend, not a steady state. The 400 percent growth in critical risk density represents one measurement period. The underlying drivers, AI coding tool adoption, AI infrastructure deployment, expanded tooling supply chains, and deployment velocity outpacing security review cycles, are all still growing.
Model release cadence has accelerated to roughly one significant update every 72 hours across the major AI labs, according to tracking from the AI developer community. Each new model release drives adoption of new infrastructure, new integrations, and new deployment patterns. The organizations that are deploying the most aggressively are also the organizations most likely to be contributing to the critical risk density increase OX Security measured.
Sysdig’s observation that AI-infrastructure CVEs are being exploited within hours of disclosure will not improve as the infrastructure category grows. More AI infrastructure deployments mean more potential targets for attackers scanning GitHub advisory feeds. The 12-hour window for LMDeploy may represent a current state that gets shorter as attackers build more automated tooling for scanning and exploiting AI infrastructure advisories. The pattern Sysdig describes over the past six months shows increasing speed, not stabilization.
What Security Teams Need to Change to Operate in This Environment
The traditional vulnerability management workflow is not adequate for the environment the OX Security data describes. Three changes address the structural gaps directly.
Replace CVSS-first triage with context-first triage. The OX Security data shows that business priority and PII processing are the dominant elevation factors for critical risk, not CVSS severity. Security programs that have not operationalized context-based triage are deprioritizing their most important findings. The change requires maintaining better asset context (what does this service do, what data does it handle, what business process does it support), not better scanning. The scanning is already surfacing the findings. The triage is sorting them incorrectly.
Apply AI infrastructure inventory as a first-class security practice. vLLM, LMDeploy, TGI, Ray Serve, MCP server libraries, RAG retrieval frameworks, agent orchestration tools: any of these running in a production environment without SBOM tracking represents a CVE blind spot. The MCP ecosystem alone has 97 million monthly SDK downloads and a growing catalog of documented attack vectors. Inventory of AI-specific tooling should be a standing practice at organizations doing AI development, not an ad hoc task triggered by incidents.
Match patch cadence to advisory velocity for AI infrastructure. The 12-hour exploitation window for CVE-2026-33626 means that monthly patch cycles and weekly scan cadences are not adequate controls for AI infrastructure. The same tool that ships patches to AI inference servers on a monthly cycle would have left LMDeploy exposed for at least two weeks after the advisory was published. AI infrastructure tooling requires a separate, faster patch cadence, with automated alerting for new advisories and same-week patch requirements regardless of whether CISA KEV or enterprise scanning has flagged the tool.
The 400 percent growth in critical vulnerability density is not a prediction. It is what happened over the past 90 days across 250 organizations that OX Security measured. The organizations in that sample are operating in a security environment that their current tools and processes were not designed for. The architectural analysis of AI coding tools makes clear how deeply integrated these systems are in the development process. The security implications of that integration are now appearing in the measurement data. Understanding the structural cause of the density increase is the first step toward addressing it before the next 90-day interval looks even worse.