The AI Vulnerability Tidal Wave
Security Strategies Need to Adapt or Drown
In April 2026, the U.S. government’s National Vulnerability Database, the closest thing the industry has to an official scoreboard for software flaws, admitted it had lost the race. NIST “enriched” (added severities and other info to) nearly 42,000 vulnerabilities in 2025, 45% more than any year in its history, and it still couldn’t keep up. We have been unable to clear that backlog,” NIST wrote, marking many vulnerabilities from 2024 and some CVEs through March 1st of this year as “Not Scheduled” and moving on.
And it’s not just NIST. Here at IronCore, our engineers are spending noticeably more time on security updates than we were a year ago: more dependency bumps, more dependabot issues, more CVE triage, more (mostly bogus) security bug bounty submissions, and more time verifying that all the updates don’t break our software. It’s impacting our productivity.
And it’s not just us: the whole industry is bailing water.
The vulnerability wave
The number of CVEs published per year has gone from 6,517 in 2016 to 49,972 in 2025, per the NVD API. That’s a 667% increase over the decade, and the rate of increase is accelerating.
2026’s projected value in the above chart is based on the current rate, which could change, so let’s compare apples-to-apples this year so far versus the same period last year. From January 1 through May 21, the NVD published 19,803 CVEs in 2025 and 26,695 in 2026. That’s a 35% jump.
Zoom into the big vendors and the picture gets less clear, but it’s worth being honest about that. Here’s what select companies counted over the exact same window, January 1 through May 21, in both years:
| Vendor | What’s counted (Jan 1 – May 21) | 2025 | 2026 | YoY |
|---|---|---|---|---|
| Microsoft | CVEs fixed across the 5 Patch Tuesdays (excl. out of band) | 477 | 538 | +13% |
| Apple | CVEs fixed in flagship iOS/iPadOS releases | 159 | 152 | −4% |
| Cisco | CVEs in the scheduled IOS / IOS XE + IOS XR bundles (excl. firewall) | 36 | 16 | −56% |
| Palo Alto | Official security advisories published | 41 | 39 | −5% |
Counts pulled for the identical window from: MSRC Patch Tuesday releases, Apple security releases, Cisco PSIRT bundle advisories, and the Palo Alto advisory portal.
Looking only at these numbers, it’s a mixed bag. Microsoft is up modestly, but Apple, Cisco, and Palo Alto all shipped fewer fixes than they did in the same window last year. In other words, the big-name vendors aren’t where that 35% surge is coming from. It’s spread across the long tail of everything else. So are they immune?
A normal month for Palo Alto has only a handful of advisories, but in May this year, they had 25. That’s the largest batch on record. Of those 25, only 4 are rated High or Critical by Palo Alto’s advisory portal, but 22 of the 25 have a CVSS score of 7.0 or higher.
Palo Alto has downgraded the severities versus what NIST thinks. For example, three of the vulnerabilities are remote-code execution with CVSS scores of 9 or 10 (critical), but Palo Alto deemed them less severe.
While Cisco and Palo Alto shipped fewer security fixes in 2026 so far, the ones they did ship were scarier. Cisco’s ArcaneDoor persistence (April 2026) burrows into firmware and survives the patch, and Palo Alto’s CVE-2026-0300 was a root-level firewall zero-day already being exploited in the wild before a fix was shipped. Also, these numbers look only at Cisco iOS, but if you include their firewall product, Cisco has a small uptick.
More worrisome: time to exploit is negative
Mandiant’s M-Trends report 2026 shows an incredible drop in the time to exploit, which measures how long between a vulnerability’s announcement and detected exploitations of it. This year, that number plummeted to -7, which means vulnerabilities are being exploited on average a week before a patch is available.
Meanwhile, Verizon’s DBIR 2026 shows that exploitation of vulnerabilities is now the number one cause of breaches by a fair margin:
Worse, it’s taking organizations longer to update software even after they know it has vulnerabilities that are being exploited. From the DBIR:
The median time for full resolution went up to 43 days, almost two weeks more than the previous year’s 32 days.
And the number of critical vulnerabilities to patch has also gone up. From the same report:
In the median case, organizations had 50% more critical vulnerabilities to patch in this year’s reporting dataset compared to the previous year.
Number of vulnerabilities is up, probably due to AI; time to exploit is now an impossible-to-defend-against -7 days; and average time to patch known exploited vulnerabilities is a record high 43 days.
Whether AI is to blame or not, this is a bad situation.
Why now?
It’s tempting to assume AI is the cause and leave it there. And it probably is. But there are at least three separate AI effects in play here that are worth teasing apart.
1. Deluge of garbage AI vulnerability reports
The most concrete, best-documented effect is a flood of low-quality, AI-generated vulnerability reports. We’ve been getting these here at IronCore, especially lately, but Daniel Stenberg of curl has been struggling with this for more than a year.
By mid-2025, AI “slop” made up roughly 20% of all security submissions to the curl project, while only about 5% of submissions turned out to be genuine vulnerabilities. Each bogus report, “engages 3-4 persons. Perhaps for 30 minutes, sometimes up to an hour or three. Each.”
In January 2026, curl shut down its bug bounty entirely due to the low quality reports. And a week ago, Linus Torvalds said, “the continued flood of AI reports has basically made the [linux] security list almost entirely unmanageable.”
Note: the invalid garbage reports do not impact the CVE numbers, but this is still an important leg of the stool for how AI is impacting security teams dealing with vulnerabilities and reports. And some of those zero-effort AI reports are, in fact, real finds.
2. Real security flaws uncovered by AI
The flip side is that some of those numerous reports actually find real problems.
Anthropic’s Mythos may be largely hype, but it is finding real issues across the ecosystem (even in curl, though only one of five reported issues was real, and it was low severity).
DARPA’s AI Cyber Challenge, which wrapped at DEF CON 33 last August, found 86% of 63 synthetic bugs planted across 54 million lines of code and then patched 68% of them. Along the way, they stumbled into 18 real, previously-unknown zero-days.
In January, there were 12 OpenSSL security issues fixed, and all of them were reported by a single AI startup (only one was high severity). One of the bugs dated back to the original creation of the project in the 90’s.
This is a mixed bag, as AI can be used to make our software better when the good guys use it. It’s not so great when the bad guys find things first.
3. Inherently insecure AI slop code
The third effect is the one I most worry about. The industry is now generating enormous volumes of code with AI assistants, and much of it is insecure. While AI is capable of finding and fixing security issues, it is also likely to create them. Here’s some relevant data:
| Study | What they measured | The result |
|---|---|---|
| NYU, “Asleep at the Keyboard?” | 1,689 programs from GitHub Copilot across 89 scenarios | ~40% were vulnerable |
| Stanford (Perry et al.) | Developers writing security-sensitive code with vs. without an AI assistant | AI users wrote less-secure code and were more confident it was secure |
| Veracode 2025 GenAI report | 100+ LLMs across 80 coding tasks | 45% of AI-generated code introduced flaws; newer/bigger models were no better |
The odds of AI generating vulnerable code are high. The root cause is that models aren’t taught to write secure code.
As of today, not a single system card for OpenAI, Anthropic, Google, Meta, or xAI mentions any reinforcement learning that rewards securely written code.
Frontier models are trained to spot vulnerabilities, but not to write code that’s secure to start with.
Our best hope here is that the frontier model makers (and open source ones, too) start prioritizing security in generated code during training.
Until then, vulnerable code is being spewed at unprecedented rates.
What to do
Put the three together and the numbers make sense. AI is manufacturing vulnerabilities (insecure code), discovering them faster (both good and bad actors), and burying the humans who triage them under noise. The result is the curve you saw at the top of this post.
It begs the question: if a vulnerability is exploited, then what?
The brutal answer for most organizations: if your data sits in plaintext in a database, a search index, or an S3 bucket that the compromised box can access, then your data is gone. Not “at risk.” Exfiltrated. On sale. You’re writing breach notifications and calling insurance companies.
Make a breach survivable with application-layer encryption
Instead of betting everything on a “they’ll never get in” design, construct your security so that when they get in, they get nothing useful. That’s application-layer encryption (ALE): you encrypt sensitive data in your application, before it lands in the database, the search cluster, the analytics pipeline, or the SaaS vendor’s storage. A compromise of those data sources is not necessarily a compromise of your encrypted data.
The attacker has to gain access to both the data AND the key(s) protecting it, and the keys are some of the best protected data in any infrastructure.
It’s because the keys are the whole game that Hold Your Own Key (HYOK) matters so much. With HYOK, your encryption keys live in infrastructure you control even when the data lives elsewhere, like with a SaaS provider. You hold your keys in Hardware Security Modules (HSMs), and, if the ALE construction is strong, the keys never leave your secure storage.
This is layered security that works.
IronCore’s ALE accelerating technology
This is the entire premise of what we build at IronCore. SaaS Shield gives SaaS platforms multi-tenant application-layer encryption with BYOK/HYOK, high availability and high performance. Cloaked Search keeps data encrypted even while it’s being searched in Elasticsearch or OpenSearch. Cloaked AI does the same for the vector embeddings powering your AI features. In every case, sensitive data is tightly controlled, and an attacker’s job is exponentially more difficult.
The bottom line
The vulnerability wave is real, it’s measurable, and AI is shaking it into a tsunami: more insecure code going in, faster bug discovery on both sides, and a rising tide of noise drowning the people who triage.
At this point in time, it’s impossible to patch fast enough to be immune from exploitation. The average vulnerability is exploited seven days before a patch even exists.
While we all need to patch faster and automate more to narrow the window, patching is a race we cannot win.
The defense that actually changes the outcome is assuming the breach will happen and making sure that when it does, the attacker walks away with encrypted gibberish instead of your or your customers’ sensitive data.
Because once the plaintext data’s out, it’s gone. No patch will bring it back.
If you want to talk through where application-layer encryption and HYOK fit in your stack, we’d love to help. And if you’re building AI features on sensitive data, start with our paper on AI Shadow Data.
