Between 1 January and 31 July 2026, 45,626 CVE records were published. The same window in 2025 produced 27,426. That is a 66% increase, roughly 291 new vulnerabilities per day, and the trend line has not bent since. The comfortable explanation is that software is simply bigger. The honest one is that the economics of finding bugs changed this year, and they changed for both sides at once.
Where the spike actually comes from
The spike has two engines, and it is worth separating them because they need different responses.
The first engine is the AI stack itself. The software everyone rushed into production is young, thinly reviewed, and dangerously permissive by design. AI-related software produced roughly 870 CVEs in 2025; the first five months of 2026 alone passed 1,200. The MCP ecosystem generated more than 30 CVEs in the first sixty days of the year. In a single October week, one tracking service logged 39 AI security stories, twelve of them carrying CVEs. Frameworks like LiteLLM, Flowise, and Langflow have each already shipped credentials-stealing backdoors or unauthenticated RCE. We are security-auditing in production the plumbing we adopted in a weekend.
The second engine is discovery. Autonomous scanners pointed at codebases, API surfaces, and protocol implementations are filing findings at a rate no human triage process was designed for. One analysis puts the AI-discovered share of disclosures at 3.5 times last year's level. The uncomfortable detail is what did not move: of the tens of thousands of CVEs published through July, only 172 are known to have been exploited, about 3.77 per thousand, the lowest signal density on record. The queue is filling with noise at machine speed, and the same patch teams are expected to drink from the firehose.
How the attacks actually run now
The seasonal number that matters is not the count of CVEs. It is the time between discovery and exploitation, because AI collapsed it.
Consider the pattern that repeated itself this autumn. AI-assisted research found a family of remote code execution flaws in a widely deployed PHP interpreter. The findings leaked before vendors shipped fixes, and attacks started inside the disclosure gap. A separate agent-driven campaign used AI reconnaissance tooling against more than 2,250 cloud tenants with stolen credentials, confirmed by Microsoft's threat intelligence team. Another tracked operation ran 8,257 agent messages across 133 sessions, hit 62 named organizations, and cost its operators about $24,000 in model spend. A honeypot caught an offensive agent renting exposed LLM endpoints as its brain, carrying 74 integrated tools. None of these required the operators to understand the exploit. That was always true of metasploit-era crime; what is new is the reconnaissance, the chaining, and the tailoring now run at machine speed, which is why signature-based detection keeps losing. Every attack is bespoke.
The guardrail tax on defense
Here is the part of the story that gets discussed in policy panels and almost never in incident channels. The same frontier models that power the attacks sit behind usage policies that were hardened this year, in many cases specifically because of campaigns like the ones above. The hardening was aimed at the right target. The blast radius landed on the wrong one.
Ask a frontier model to help you triage a suspected injection in your own codebase, verify an exploit against a system you own, reverse a suspicious binary, or fuzz your parser before a release, and you will sometimes get help. Increasingly, you will get a refusal, or a demand for proof of authorization that no API has a field for. Professional pentesters and vulnerability researchers report the same drag: workflows that ran through a model in minutes now route around it. Security vendors are quietly redesigning products around the constraint, moving to multi-model architectures and self-hosted open weights precisely because the hosted refusal gates fire mid-investigation. The research community is even publishing the first formal frameworks for when security agents should refuse, which tells you the current policy is vibes enforced at scale.
Set the two sides side by side and the asymmetry is hard to miss:
| The Defender | The Attacker | |
|---|---|---|
| Model access | Hosted APIs, refusal gates, full logging, account linkage | Jailbreaks, open-weight models, rented endpoints with no terms of service |
| Authorization | Scope letters, program IDs, procurement, audit trails | None, and none needed |
| Speed | Approval chains, change windows, patch cycles | Discovery to exploitation inside the disclosure gap |
| Cost | Platform spend plus compliance overhead | About $24,000 of inference for a 62-organization campaign |
This is what unilateral disarmament looks like in software. The guardrails bind exactly one population: the people who follow rules. The campaigns driving the hardening ran on jailbroken accounts, open models, and stolen API keys, none of which encountered a refusal gate on the way in. Refusal is not a security control. It is a liability shield, and pretending otherwise just means your own team works with weaker tools than the people testing them.
What we actually do about it
None of this is an argument for dropping models from security work. It is an argument for architecture that assumes the refusal:
Keep dual-use work on weights you host. Exploit verification, payload analysis, and reverse-engineering assistance belong on self-hosted open-weight models in an isolated segment, not on a hosted endpoint that can terminate your session mid-incident. Evaluate the open frontier quarterly; the gap is smaller than most policies assume.
Carry authorization in the context. Where you do use hosted models for defensive work, scope letters, bug-bounty program identifiers, and asset ownership evidence in the prompt measurably reduce false refusals. Enterprise defensive tiers exist at most major labs and almost nobody bothers to enroll. Do the paperwork before the incident, not during it.
Never route breach traffic through third-party endpoints. Mid-incident, the model is both a data-exfiltration risk and a single point of refusal. Runbooks should assume the hosted model is unavailable during an active investigation, the same way they assume the office internet might go down.
Let tools execute and models orchestrate. Fuzzers, SAST, dependency audits, and detection rules are boring and they never refuse. The model's job is triage, correlation, and drafting the fix, not being the exploit engine.
Budget for judgment. When discovery is free, the scarce input is no longer finding bugs or writing patches. It is deciding which of 291 daily CVEs matter for your stack. That is a human-plus-model role, and it deserves a named owner, not a rotation.
The honest conclusion
The CVE spike is not going to reverse, and it should not. More eyes on more software was always the promise of the ecosystem; AI simply made it true faster than our triage processes adapted. The part we can still shape is the asymmetry. Guardrails that cannot tell a red team with a contract from a ransomware crew with a stolen key will keep binding only one of them, and the incident data shows exactly which one. Until refusal policies get real authorization pathways, build your security workflow on the assumption that the strongest models will be unavailable exactly when you need them most.
For the adjacent reading, start with why perimeter filters fail against prompt injection, tool poisoning as the new injection class, and our position that security is not a feature you add late.