{"id":8214,"date":"2026-05-20T09:00:00","date_gmt":"2026-05-20T09:00:00","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=8214"},"modified":"2026-05-20T09:00:00","modified_gmt":"2026-05-20T09:00:00","slug":"why-some-security-fixes-never-reach-your-vulnerability-dashboard","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=8214","title":{"rendered":"Why some security fixes never reach your vulnerability dashboard"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

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\u2019s npm publishing path<\/a> through a compromised GitHub Action related to the Checkmarx supply chain incident that affected several other downstream consumers that week.<\/p>\n

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

Notice what CVE actually does, though. It doesn\u2019t 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\u2019s incident response, not vulnerability tracking.<\/p>\n

This is the system functioning by 2026 standards. That\u2019s a long way from what CVE was built to do.<\/p>\n

The drift<\/h2>\n

CVE launched in 1999 as a vulnerability identifier. The original definition<\/a> 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<\/a> in OpenSSL 1.0.1f. The deserialization flaws in Apache Struts. Patch the version, scan to verify, dashboard turns green.<\/p>\n

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

CVE was now tracking incidents<\/em> rather than defects in code.<\/p>\n

Attacks like s1ngularity and Shai-Hulud<\/a> 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<\/a>, but most didn\u2019t. Red Hat\u2019s advisory on the campaign acknowledged the obvious<\/a>: \u201cdue to the unprecedented number of impacted organizations and individuals, it is unlikely that all package infections will be assigned CVE identifiers.\u201d\u00a0<\/p>\n

Interestingly, the Bitwarden compromise from late April is itself a Shai-Hulud variant, with the string \u201cShai-Hulud: The Third Coming\u201d embedded<\/a> in the malicious payload. It got a CVE because it\u2019s one identifiable package with one identifiable bad version. The 700-plus packages from earlier waves of the same campaign mostly didn\u2019t.<\/p>\n

Vendors also quietly fix things<\/a> without disclosure. A researcher\u2019s report gets closed as informative<\/a>, the issue ships in the next release as a \u201chardening improvement\u201d or better yet \u201csecurity enhancement\u201d (not a fix). No CVE is requested. Sometimes that\u2019s reasonable \u2014 not always. Either way, no defender\u2019s tooling sees it, and AI is making it worse.<\/p>\n

What agents do to all of this<\/h2>\n

The category that breaks the framework most clearly is the one with no existing identifier scheme to begin with.<\/p>\n

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\u2019t 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\u2019t map to any existing weakness category.<\/p>\n

For example, a skill called derp<\/a> 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\u2019s doing so. A CVE has nothing to point at. No memory corruption, authentication bypass, or a CVSS vector. The harm, however, is real \u2014 wasted hours, eroded trust in the agent, an inflated bill for compute\/tokens \u2014 but it\u2019s behavioral<\/em>. A scanner looking for malicious patterns will not catch it.<\/p>\n

derp is small, but structurally identical attacks aren\u2019t. In my research at Manifold Security this April, we identified the ClawSwarm campaign<\/a> which catalogs 30 skills published by a single ClawHub author. Some of these include utilities<\/a> like Cron Helper (903 downloads) and Agent Security (685 downloads) that quietly enroll the user\u2019s 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\u2019s economy without the operator\u2019s knowledge.<\/p>\n

What\u2019s the CVE for that? These skills aren\u2019t malware in any traditional sense. The HTTPS calls are documented. The wallet generation uses a legitimate SDK. There\u2019s 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.<\/p>\n

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\u2019t always pronounced within release notes. The vulnerability that worked on yesterday\u2019s model and fails on today\u2019s gets bundled into a capability update or new \u201csafeguards<\/a>\u201d 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.<\/p>\n

A recent academic survey<\/a> of 295 GitHub Security Advisories that referenced LLM-related components found that existing CWE metadata<\/a> 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: \u201cCurrent GHSA metadata lacks structured indicators of LLM involvement, requiring manual classification to identify model-mediated exposure patterns.\u201d<\/p>\n

CVE-2025-68664 in LangChain Core<\/a>, a deserialization flaw triggerable through prompt-influenced metadata, is a rare case that did make it into the system, but most don\u2019t. 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.<\/p>\n

Both are exploitable, but only one is being tracked.<\/p>\n

What a workable signal layer looks like<\/h2>\n

CVE still does its job for what it was designed for. But the assumptions underneath the framework \u2014 stable identity, fixed content, coordinated disclosure, vendor advisories \u2014 don\u2019t hold for a meaningful and growing share of the agent attack surface.<\/p>\n

A workable signal layer for this category probably needs three things the current system lacks.<\/p>\n

Behavioral identifiers rather than artifact identifiers<\/strong>: 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 \u2014 what data flows where, what external services it enrolls itself with, what tool calls it makes on a user\u2019s behalf \u2014 gives you something durable to track even when the upstream artifact is ephemeral.<\/p>\n

Registry transparency for takedowns<\/strong>: When npm removes a package, there\u2019s a paper trail<\/a>. When a Skills registry removes a publisher, there often isn\u2019t. The ecosystem will mature on this front, but enterprise consumers should be pushing for it now rather than waiting.<\/p>\n

Responsible disclosure, but for vendors: <\/strong>We need an honest accounting from vendors about what they fix and ship silently, including model vendors. I\u2019m 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<\/a>.<\/p>\n

The dashboard you have was built for the threats you had<\/h2>\n

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.<\/p>\n

What won\u2019t 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\u2019s network because a SKILL.md told it to.<\/p>\n

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\u2019ve stopped watching, is where the work starts.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

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\u2019s npm publishing path through a compromised GitHub […]<\/p>\n","protected":false},"author":0,"featured_media":8215,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-8214","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/8214"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=8214"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/8214\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/8215"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=8214"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=8214"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=8214"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}