
The upgrade trap: when upgrading is the wrong answer to a CVE
Aikido argues that the reflexive SCA-tool advice to 'just upgrade' to fix a CVE breaks down in three cases: no fixed version exists (e.g. the deprecated Node.js 'request' package's SSRF advisory), the fix hasn't shipped yet (lodash CVEs affecting all versions up to 4.17.23), or the fix ships with breaking changes (Node.js CVE-2026-48937, which bundled a fix with removal of HTTP/2 priority signaling). It also cites the chalk/debug npm maintainer-account compromise as evidence that blind auto-upgrading can pull in malware, and pitches backporting isolated fixes to already-deployed versions (via Aikido Libraries) as the alternative to upgrade-or-freeze.
What it is
Aikido's argument for decoupling "the version you run" from "the security fixes applied to it." Beyond the three-failure-case framing in the summary, the page gives concrete remediation paths for each named case and introduces backporting as the alternative to upgrading.
What to do
The page states specific actions per case, which the summary does not:
request(SSRF advisory, no fix ever coming): the package has been deprecated since 2020 and the advisory notes the flaw affects every version the maintainer supports (i.e. all of them). "Upgrade" here actually means rippingrequestout and migrating to axios or node-fetch — a rewrite, not a version bump.- Node CVE-2026-48937: the fix is bundled with a SEMVER-MAJOR
nghttp2update that removes HTTP/2 priority signaling; you cannot take the fix without the breaking change. Before you can upgrade at all, grep your code forsetPriorityand.priority()and remove them. - lodash (two CVEs through 4.17.23): there was nothing to upgrade to because the latest published version was itself affected;
npm auditreported no fix available. The action is to wait for a patched release or backport — upgrading was sound advice but not feasible.
The page's proposed general answer for EOL/unpatched cases is backporting: someone understands the vulnerability and writes a fix for the version already in use, the way OS distros have done for years, now applied to application libraries.
Preconditions / Affected
- Pipelines set to auto-update — these are what pulled the malicious chalk/debug versions straight in within minutes of publication.
- Codebases still transitively depending on deprecated packages like
request, usually dragged in by an unmaintained parent package. - Any dependency where the security fix and a breaking behavior change live in the same code path (the Node HTTP/2 case).
Caveats
- The page is explicit that "upgrade" works most of the time and remains important — the three failure modes are the exceptions, not the rule.
- The AI section claims frontier models can chain medium CVEs into critical exploit patterns, presented as an argument for urgency, not with evidence.
- The "what the industry does" section names three approaches but the fetched text is truncated mid-first-approach (screening at point of consumption); the second and third approaches — including the vendor's implied backporting pitch — are cut off, so the comparison the article builds toward is not available here.
CVEs named here
Techniques named here
- Upgrade-as-remediation reflex
- SSRF mitigation bypass
- Screening at point of consumption
- Backporting fixes to versions in use
Threat actors named here
Related in Supply Chain


