On April 15, 2026, NIST narrowed what the National Vulnerability Database will enrich. Records now receive structured metadata only if they appear in CISA’s Known Exploited Vulnerabilities catalog, affect federal government software, or fall under the critical software definition in Executive Order 14028. Everything else is marked lowest priority. Every backlogged record with an NVD publish date earlier than March 1, 2026 moved into a category called “Not Scheduled”.
CVE submissions rose 263% between 2020 and 2025. NIST enriched nearly 42,000 records in 2025, 45% more than any prior year, and submissions in the first quarter of 2026 still ran about a third ahead of the same period the year before. The feed that most scanners read is now incomplete by design, and a record without CPE mappings or a CVSS score is a record automated tooling cannot match against your lockfile. That is the smaller of the two problems.
What a CVE record actually asserts
A CVE is a narrow claim: there is an accidental defect in published code, and the party who publishes that code is expected to correct it. Three assumptions sit underneath the claim, and every remediation workflow built on CVE data inherits all of them.
| The record assumes | The workflow depends on it because |
|---|---|
| The defect is accidental | Detection can wait for public disclosure. Nobody is racing you to exploit their own mistake. |
| The maintainer is a defender | A fix will exist, and the fix comes from the same account that shipped the defect. |
| A newer version is a safer version | ”Upgrade to the patched release” is only sound advice if forward means better. |
These hold well for the case the model was built for. A memory-safety bug in a parser or an authentication bypass in a web framework: the maintainer wants it gone as much as you do, and the remediation is genuinely to move forward.
All three invert when the package is the attack
When a publishing account is taken over, the party shipping the code is the adversary. The defect is deliberate, so there is no disclosure to wait for. No fix is coming from that account, because the account is the source. Forward is the direction the payload lives in.
The third inversion is the one that does real damage, because it turns standard advice into a delivery mechanism. On September 8, 2025, a maintainer account behind a set of widely used npm utilities was phished through a convincing account-lockout email that captured both the password and the one-time code. Malicious versions went to the registry at 13:16 UTC. The community flagged the code around 15:20 UTC, and clean versions were restored within roughly two hours. Eighteen packages were affected, together drawing over two billion downloads a week.
For the length of that window, the newest published version of those packages was the malicious one. Any policy that says stay current, and any automation that opens and merges version bumps without delay, pointed directly at the payload. The scanner was accurate about every version it already knew, and had nothing to say about the one that had just arrived.
The ecosystem already conceded this, in its identifier scheme
As a rule, malicious packages get a different identifier entirely: MAL- rather than CVE-. The OpenSSF runs a malicious-packages repository that publishes reports in the OSV format, and OSV serves those records under that separate prefix, covering typosquatting, dependency confusion, protestware, and outright malware. A record like MAL-2025-6812 is not a CVE, and it does not become one.
The prefix separates two claims that call for opposite responses. A CVE says there is a defect in something you should keep using once it is patched, while a MAL- record says the artifact should not be in your tree at any version. Merging them into one namespace would have meant one identifier for two incompatible remedies.
A scanner whose only input is a CVE feed therefore reads a namespace that excludes this category by construction, and no amount of faster ingestion closes that. The data source was never built to hold these records.
Where agents shop, there is often no record to find
CVE and CPE vocabulary grew up around software products with vendors and version strings. Coverage for the artifacts an AI agent actually consumes is thin and uneven by comparison. Model weights, MCP servers, agent skills, and editor extensions all carry executable behavior, and none of them fit the product-and-version shape that CPE matching expects.
The sharpest version of the gap is a category where no record can exist even in principle. Code-generating models routinely name dependencies that were never published. Measured hallucination rates run from about 5.2% on commercial models to 21.7% on open-weight ones, and a USENIX Security 2025 analysis of 2.23 million generated samples found that 19.7% referenced at least one package that does not exist, cataloguing 205,474 distinct fabricated names.
Those names are stable enough to be worth squatting. Re-running the same prompt ten times, researchers saw 43% of hallucinated names reappear every single time. An attacker who registers one is not competing with a legitimate package. The first version published under that name is malicious from the first line, with no prior release and no maintainer history behind it. A scanner asked about it has nothing to match, because there is nothing known to be wrong with a package that had no honest past.
What a CVE feed is still good for
None of this makes vulnerability scanning optional. A CVE feed answers a real question well: is there a publicly known defect in something I have already decided to trust. Patch prioritization and reachability analysis both depend on it, and the KEV-first enrichment policy arguably makes what remains more useful for triage, since what survives the cut is what is actually being exploited.
What a CVE feed cannot answer is whether you should have trusted the artifact at all, and that second question is where the 2026 attack volume sits. What covers it is different in kind:
- Delay automated adoption. A cooldown on version updates costs a few days and removes the window that a hijacked release depends on. Dependabot’s three-day default is the ecosystem-wide version of this.
- Constrain what an install may do. Blocking lifecycle scripts removes the most direct path from download to execution. npm v12 makes this the default, including the implicit
node-gyp rebuildthat abinding.gypfile triggers, which a June 2026 self-propagating worm used to run code on install across dozens of packages. - Weigh provenance, not just version. Account age, publishing cadence, whether releases carry attestations, and how a package came to be in your tree at all.
- Ask what else the same source shipped. A single flagged artifact is rarely alone. The account behind it usually has others live under different names, in other ecosystems, unflagged.
The last one is the question a per-artifact scanner is structurally unable to ask, because it evaluates one file at a time and has no memory of what else arrived with it.
Where Aephix fits
That last question is the one Aephix answers. Aephix is threat intelligence for the AI agent supply chain. It is not a scanner and not a replacement for one, and it would not have told you about any CVE listed in your last report. What it covers is the category the CVE namespace excludes on purpose.
Before you install a package or connect to a server, Aephix Vantage gives you a free, cross-ecosystem view of what is already known to be malicious, so an artifact with a hostile history is something you recognize before you connect. When you are looking at a malicious package, model, skill, MCP server, extension, or container, Aephix Sleuth links it to the wider operation behind it, with a confidence level and supporting evidence, so you can act against the whole operation rather than the single file in front of you.
The next hijacked release will not have a CVE on the day it reaches your lockfile. It will have a publisher whose other work is already live somewhere you have not looked.