Why some security fixes never reach your vulnerability dashboard

On April 22, for roughly 90 minutes, a malicious version of Bitwarden CLI appeared on npm. Version 2026.4.0 contained a credential-stealing payload that executed an obfuscated loader and harvested AWS, Azure, GCP, GitHub, and npm tokens from any developer machine that ran npm install. The attackers reached Bitwarden’s npm publishing path through a compromised GitHub Action related to the Checkmarx supply chain incident that affected several other downstream consumers that week.

About nine days later, CVE-2026-42994 was issued by Bitwarden for the trojanized version. Defenders running a software composition analysis tool began seeing it on their dashboard. Detection engineers started writing rules. The incident got a writeup, an entry in someone’s threat intelligence feed, and a row in next quarter’s metrics deck.

Notice what CVE actually does, though. It doesn’t tell anyone to patch a flaw. The flaw was a 90-minute window in which a publishing pipeline was compromised, and the window has closed. The CVE is a retroactive notification. Meaning, if you ran npm install during that window, treat your developer credentials as exposed. That’s incident response, not vulnerability tracking.

This is the system functioning by 2026 standards. That’s a long way from what CVE was built to do.

The drift

CVE launched in 1999 as a vulnerability identifier. The original definition was tight: a flaw in a system that violates a security policy, with a fix that defenders can apply against a known version range. Heartbleed in OpenSSL 1.0.1f. The deserialization flaws in Apache Struts. Patch the version, scan to verify, dashboard turns green.

MITRE and CNAs began stretching the framework almost immediately. The SolarWinds incident of 2020 got CVE-2020-10148, but the “vulnerability” was a backdoor inserted into a signed update, not a code flaw the maintainer wrote. node-ipc/peacenotwar in 2022 got CVE-2022-23812 for protestware that wiped files based on geolocation. The fix in both cases was “remove the bad version,” not a patch to a defective component. The identifier still worked, but it was no longer doing the job it was designed for.

CVE was now tracking incidents rather than defects in code.

Attacks like s1ngularity and Shai-Hulud broke the stretch. The self-propagating npm worm that emerged in September 2025 and returned in escalating variants through 2026 infected hundreds of packages across the ecosystem. Some affected versions got CVEs, but most didn’t. Red Hat’s advisory on the campaign acknowledged the obvious: “due to the unprecedented number of impacted organizations and individuals, it is unlikely that all package infections will be assigned CVE identifiers.” 

Interestingly, the Bitwarden compromise from late April is itself a Shai-Hulud variant, with the string “Shai-Hulud: The Third Coming” embedded in the malicious payload. It got a CVE because it’s one identifiable package with one identifiable bad version. The 700-plus packages from earlier waves of the same campaign mostly didn’t.

Vendors also quietly fix things without disclosure. A researcher’s report gets closed as informative, the issue ships in the next release as a “hardening improvement” or better yet “security enhancement” (not a fix). No CVE is requested. Sometimes that’s reasonable — not always. Either way, no defender’s tooling sees it, and AI is making it worse.

What agents do to all of this

The category that breaks the framework most clearly is the one with no existing identifier scheme to begin with.

Skills, MCP servers, and the wider scaffolding around AI agents have several properties the CVE framework was never designed to handle. They mutate at runtime. The operative payload is often a natural language instruction that an agent reads and executes, meaning agentic assets don’t always have stable identities. They get pulled from public registries but also shared via Slack or forked from a repo that looked official three months ago. The harm doesn’t map to any existing weakness category.

For example, a skill called derp on the skills.sh registry illustrates the problem. It contains zero traditional malware indicators. No network calls, base64 blobs, or credential paths. The SKILL.md instructs Claude to deliberately produce broken code, then offer broken fixes in a loop, while hiding the fact that it’s doing so. A CVE has nothing to point at. No memory corruption, authentication bypass, or a CVSS vector. The harm, however, is real — wasted hours, eroded trust in the agent, an inflated bill for compute/tokens — but it’s behavioral. A scanner looking for malicious patterns will not catch it.

derp is small, but structurally identical attacks aren’t. In my research at Manifold Security this April, we identified the ClawSwarm campaign which catalogs 30 skills published by a single ClawHub author. Some of these include utilities like Cron Helper (903 downloads) and Agent Security (685 downloads) that quietly enroll the user’s AI agent into a third-party network. Install one, and the agent registers itself with an external server, reports its capabilities, generates a Hedera crypto wallet, stores credentials on disk, and polls for tasks every four hours. The skills work. They also recruit the agent into someone else’s economy without the operator’s knowledge.

What’s the CVE for that? These skills aren’t malware in any traditional sense. The HTTPS calls are documented. The wallet generation uses a legitimate SDK. There’s no shellcode to flag or a known C2 to block. Even if a registry pulls the campaign, the same pattern can reappear under a different author with a different filename in a week. The artifact-centric model has nothing to grip.

Frontier model vendors face a variation of the problem. They do version their releases (Sonnet 4.6, Opus 4.7, GPT-5.1, and so on) but security fixes aren’t always pronounced within release notes. The vulnerability that worked on yesterday’s model and fails on today’s gets bundled into a capability update or new “safeguards” with no security delta called out, no advisory, and often no version bump at all when the change is to a system prompt or classifier rather than the model itself.

A recent academic survey of 295 GitHub Security Advisories that referenced LLM-related components found that existing CWE metadata captures code-level defects but systematically underrepresents model-mediated exposure, the cases where the vulnerability is triggered or amplified through model reasoning rather than a flaw in the surrounding code. As the authors put it: “Current GHSA metadata lacks structured indicators of LLM involvement, requiring manual classification to identify model-mediated exposure patterns.”

CVE-2025-68664 in LangChain Core, a deserialization flaw triggerable through prompt-influenced metadata, is a rare case that did make it into the system, but most don’t. A prompt injection technique that lets an attacker exfiltrate tool-call outputs from an agent could get fixed in the next model checkpoint, surface in a research paper six months later, and never appear on any dashboard.

Both are exploitable, but only one is being tracked.

What a workable signal layer looks like

CVE still does its job for what it was designed for. But the assumptions underneath the framework — stable identity, fixed content, coordinated disclosure, vendor advisories — don’t hold for a meaningful and growing share of the agent attack surface.

A workable signal layer for this category probably needs three things the current system lacks.

1. Behavioral identifiers rather than artifact identifiers: If a skill that instructs an agent to exfiltrate environment variables gets removed and the same instruction shows up tomorrow under a different author with a different filename, the relevant identifier is the behavior, not the SHA. Fingerprinting what an agent actually does — what data flows where, what external services it enrolls itself with, what tool calls it makes on a user’s behalf — gives you something durable to track even when the upstream artifact is ephemeral.
2. Registry transparency for takedowns: When npm removes a package, there’s a paper trail. When a Skills registry removes a publisher, there often isn’t. The ecosystem will mature on this front, but enterprise consumers should be pushing for it now rather than waiting.
3. Responsible disclosure, but for vendors: We need an honest accounting from vendors about what they fix and ship silently, including model vendors. I’m not optimistic about this one in the short term. Commercial incentives point the wrong way, and customer pressure (and then some from bug bounty hunters) is what tends to move vendors here.

The dashboard you have was built for the threats you had

The vulnerability tracking system was built around an artifact-centric model. It still pulls its weight for the threats it was designed for. The Bitwarden CVE landed on dashboards across the industry. So will the next one.

What won’t land is a skill pulled from a registry with no advisory. Or a model checkpoint that quietly resists a prompt injection it used to fall for. Or your agent, already enrolled in someone else’s network because a SKILL.md told it to.

If you run a security program in 2026, your dashboard is increasingly an incomplete picture. The things that will get you are not always the things on it. Knowing what your tools actually watch, and what they’ve stopped watching, is where the work starts.