The CVE spike across major software companies is a remediation problem

VC firm a16z just shared a chart that has exploded on X over the last few days. The chart shows critical and high CVEs jumping from under 100 a month to over 600 a month since Spring 2026 across 21 major software companies. The data came from Epoch AI and includes counts from Apple, AWS, Microsoft, Google, and Adobe. And because it’s X, of course people chimed in with their opinions (yes, we’re doing the same here). They were divided into two camps. One read it as a real shift in risk, while the other pointed out that known exploited vulnerability (KEV) hasn’t moved since 2024, so just because there are more disclosures doesn’t necessarily mean more danger. Even a16z’s own report hedges against this: “Whether there are actually more vulnerabilities, or whether there’s some reporting or definition change, it’s hard to say just by looking at the chart, but it’s likely that at least some (and perhaps a lot) of this parabolic growth is attributable to a major substantive change in either how vulnerabilities are discovered and/or what is still considered secure.” But both camps are reading this wrong altogether. Neither the raw count of new CVEs nor a flat KEV number actually determines risk. Risk is determined by how fast you can find out which vulnerabilities matter, and how fast they get fixed once they’re validated. It’s clear that AI has made it far easier to find vulnerabilities (for both attackers and defenders). Frontier models find vulnerabilities faster than reviewers can validate them, including long-standing bugs that survived years of manual review. So the jump in the a16z chart is indeed best explained by AI making it faster to find bugs that already existed, rather than software suddenly becoming less secure. But that's just part of the story. What happens when an institution tries to keep up with easy detection NIST, the institution that everyone treats as ground truth for vulnerability data, is dealing with the exact same problem across a larger volume. Working from the assumption that more CVEs meant more danger, it had been trying to score every CVE that came in. But the sheer volume of CVEs made this practically impossible. And eventually, the system broke. A federal audit this May found that the backlog had grown from 13,000 to over 27,000 in eighteen months. NIST’s suggested fix? To stop scoring everything. Instead, it’s prioritizing CVEs tied to federal use, critical software, or those already on CISA’s known-exploited list. Everything else is marked as “not scheduled”, and so chances are that they won’t get looked at again. NIST's struggle is about getting a vulnerability disclosed and scored. But even for the ones that clear that bar entirely - so that’s confirmed, scored, known to be actively exploited - getting them fixed is where things still seem to fall apart. Fixing is the bottleneck Verizon’s 2026 Data Breach Investigations Report, drawing on over a billion vulnerability records, found only 26% of confirmed actively-exploited vulnerabilities (on CISA’s KEV list) were fully remediated in 2025, down from 38% the year before. Median time to fully patch one rose to 43 days, up from 32. Even the best-resourced organizations only fully remediate 30-40% of these in the first week. Verizon calls this the “remediation paradox”, which is just code for vulnerabilities accelerating while remediation slows. These vulnerabilities are known to be actively exploited and sitting on a public list. And they're still not getting fixed fast enough. What fixing fast actually looks like This month, an unauthenticated RCE vulnerability called Stylesmuggler started hitting Adobe Commerce and Magento Open Source. It didn’t have a CVE attached, nor an advisory from Adobe. A vulnerability doesn't need a CVE number or a vendor advisory to be real or to be exploited. Waiting for either before you act means attackers already have a head start. The only way around that is to rely on something that can find and confirm vulnerabilities on its own, and fix them quickly once it does. Aikido Intel flagged it independently, without waiting on Adobe or a CVE number to confirm it was real. It tracked the vulnerability under three separate entities, and Aikido Libraries shipped a working fix for multiple affected versions. It was shipped as an AutoFix pull request straight into the workflow teams already use, rather than a separate, painstaking manual migration. All this before Adobe released its own hotfix over 24 hours later. StyleSmuggle isn’t a one-off, though. In Intel’s first year of operation, 67% of the packages it found vulnerabilities in were never publicly disclosed to any database (not NVD, not GitHub Advisory, not MITRE, not anywhere). So the real story is… CVE volume climbing is akin to the number of npm packages published every year, it compounds, so watching it do so is kind of… meaningless. What matters is how fast a real, confirmed vulnerability gets fixed, and right now, across the industry, it’s not fast enough. As AI commoditizes detection and exploitation capabilities, cybersecurity has to reinvent itself around what happens after something's found. That starts with knowing which of the vulnerabilities showing up are actually reachable and exploitable. Aikido's reachability analysis filters out anything with no execution path to the vulnerable code, and CVE Exploitability Analysis goes further, reasoning about how a package is actually used in your environment to decide whether a reachable vulnerability is worth acting on. Aikido does the fixing two ways. For known, patchable issues, AutoFix can generate the fix directly. For open source packages, it patches the exact version already pinned in a team's lockfile, without requiring an upgrade or migration. It works the same way for vulnerable container base images and application code. Where a fix needs a human decision, the vulnerability still gets flagged with a specific, actionable recommendation, so someone can act immediately instead of working out what to do first. The next step, doing that all the way to production without waiting on someone to merge it, isn't far off. Finding vulnerabilities has never been easier. Now, the focus should be on how you filter the vulnerabilities from the noise and fix them fast.