# What is CVE remediation in 2026? > Source: > Published: 2026-08-21 13:43:00+00:00 Common Vulnerabilities and Exposure ([CVE](/blog/what-is-a-cve)) remediation is the process of fixing or reducing the risk of security flaws in software. It used to be that finding the flaws was the hard part, but things have changed. AI has made finding vulnerabilities cheap now that [every frontier model can spot them](/blog/benchmarking-ai-models-known-cves) faster than humans can validate them. The [NVD, the US government's vulnerability database](/blog/nist-nvd-changes-2026), has quietly stopped scoring most CVEs, shelving everything filed before March 2026 as "Not Scheduled," so the severity data teams rely on to triage often isn't there anymore. The bottleneck is now remediation. But open source remediation usually means one of three imperfect options: - Upgrade and risk breaking your app - Migrate to a hardened replacement stack - Or stay pinned to a vulnerable version and wait for a patch that may never come None of these is a clean fix, which is why the decision on how to remediate depends on knowing what package versions are running in production and why. This post will cover how AI has accelerated CVE detection and discovery, the upgrade trap, what CVE remediation actually involves in 2026, and how to solve the CVE remediation problem. ## TL;DR *AI surfaces CVEs faster than teams can validate them, and the NVD has stopped scoring most of what's found. Remediation is the bottleneck. Upgrading the dependency is the usual advice, but a new release can break your build, and migrating to a replacement stack just trades one problem for another. There's another option which is backporting the fix to the version you're already running, without having to upgrade or migrate.* ## How AI has accelerated CVE discovery and disclosure The cost of finding a vulnerability has collapsed. [Annual CVE disclosures are projected to pass 60,000 in 2026](https://www.nowsecure.com/blog/2026/06/03/the-nvd-backlog-is-a-symptom-vulnerability-management-has-a-scaling-problem/), and AI is pushing from both directions. It writes more code, and reads that code for flaws faster than any human team. [Every frontier model can now find vulnerabilities](/blog/benchmarking-ai-models-known-cves) faster than reviewers can validate them. Claude Mythos Preview surfaced thousands of high-severity bugs, including [a 27-year-old flaw in OpenBSD](https://www.anthropic.com/glasswing) that survived decades of review and millions of automated tests. And it doesn't stop at finding single bugs. Models can [chain lower-severity CVEs](/blog/cve-upgrade-breaking-changes-open-source) into an exploit path that's critical in combination, even when no individual link looks urgent. The disclosure pipeline can't keep pace. Vulnerabilities are now submitted faster than anyone can enrich them, and the backlog shows it. Most new CVEs will land in the NVD as bare entries, without the severity scores and reference data that vulnerability tools rely on to prioritize and remediate. ## The upgrade trap Web applications run mostly on open source, and the conventional wisdom has always been to keep dependencies current. When a tool flags a CVE, the fix it offers is almost always to upgrade to the patched version and close the ticket. And maintainers almost always ship the fix in the newest release only. They rarely go back and patch older releases. So if you're on an older version, whether you pinned it deliberately or a parent package locked you to it, the fix upstream doesn't reach you. "Upgrade" becomes the single lever you have, and it fails in three common cases. - There's no fixed version to move to and there never will be, because the package is deprecated or abandoned. - The patch simply hasn't shipped yet, and every published version is still vulnerable. - The fix does ship, but it arrives bundled with breaking changes that take your application down with it. Even when an upgrade does exist, it usually comes at a cost. Minor version bumps can change how a package behaves and force you to re-test. Major versions mean real migration work. And the vulnerable package is often buried deep in your dependency tree, held there by a parent package's version constraint rather than any choice of yours, so you can't bump it without bumping everything sitting above it. Node's [CVE-2026-48937](https://nvd.nist.gov/vuln/detail/CVE-2026-48937) is an example of the third case. The fix shipped bundled with a `SEMVER-MAJOR` update to the `nghttp2` dependency that removed HTTP/2 priority signaling entirely. The vulnerable behavior and the removed feature came from the same underlying code, so there was no way to take the security fix without taking the breaking change with it. Anyone relying on that behavior had to grep for `setPriority` and `.priority()` and strip them out before the upgrade would even go through. Teams got conditioned to upgrade the moment they could, and attackers noticed. If everyone reflexively pulls the newest version, then the newest version is exactly where you plant malware. The[ chalk and debug compromise](/blog/npm-debug-and-chalk-packages-compromised) pushed malicious versions through the official npm channel, and every pipeline set to update automatically pulled them straight into production. Staying current now carries its own risk, which is why teams have started building in a cooldown before adopting any new package version. So you're left with a bad trade. Upgrade and you risk broken builds or a compromised package. Freeze and you sit on a known vulnerability while the security debt piles up. Read a [full breakdown on the upgrade trap](/blog/cve-upgrade-breaking-changes-open-source), with examples of all three types of upgrade failure. ## What CVE remediation in 2026 involves Before any CVE lands, it's important that you know what you run and why. Most teams can tell you their open CVE count, but if you ask why a given package or image is on the version it's on, you'll be hard pressed to get a good answer. Many hold to the common wisdom that an older version is riskier than a newer one, so they default to updating automatically. The opposite instinct, pinning a version you've tested and trust and holding it deliberately, is a legitimate choice too, as long as it's a decision you can point to rather than an accident. Getting remediation right depends on already knowing your dependency tree, and that only comes from monitoring it continuously. Treat the SBOM as a live baseline you check against new disclosures as they land. With that in place, you can decide on the right fix based on whether the vulnerable code path is reachable and, if so, whether it's exploitable in your environment. Fixing a CVE by upgrading means accepting everything else in that release, including transitive dependencies and changed defaults, so be sure you know how that new code will affect your system. Where a clean upgrade exists and you've decided the blast radius is acceptable after weighing breaking changes and transitive conflicts, take it. Where it doesn't, you're choosing between three approaches. You can: - Screen at install to catch bad packages before they reach your build, though that does nothing for what's already in production. - Move to a hardened replacement stack, which turns remediation into a migration onto an ecosystem you don't control. - Backport the fix to the version already in use, the one option that closes the CVE without pulling in a new release or a migration. ## How Aikido Libraries solves the upgrade trap [Aikido Libraries](/code/aikido-libraries) allows you to escape the upgrade trap by backporting CVE fixes to the exact package version pinned in your lockfile. When a CVE is fixed upstream, Libraries produces a secured variant of the exact version you're already running and ships it as a daily [AutoFix](/code/autofix) PR. You get the patch without the the breaking changes, or the migration. {{cta}} Under the hood it's powered by [Root's](/blog/aikido-acquires-root) factory-like system where agents generate precise CVE patches for the package versions teams actually run, then test and validate it against the version in use. It works across npm, PyPI, Maven and more, so the same approach holds whichever ecosystems your stack pulls from. Aikido Security also backports fixes for actively exploited open source CVEs, the ones on CISA's Known Exploited Vulnerabilities list, and releases them to the community for free. Libraries runs inside Aikido Security's platform alongside [SCA](/code/open-source-dependency-scanning-sca), which scans your dependencies for CVEs, malware, license, and end-of-life issues, then prioritizes what's actually reachable. SCA is powered by [Aikido Intel](/blog/aikido-intel-detects-malware-vulnerabilities-first), a real-time feed tracking both malware and vulnerabilities across open-source ecosystems. ## FAQ