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. CVE-fed scanners now operate on an incomplete feed by design.
What a CVE record actually asserts
Each CVE record 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. |
Memory-safety bugs in parsers and authentication bypasses in web frameworks fit this model. The maintainer wants the defect gone as much as you do, and the remediation is 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, and no fix is coming from the same account that published the payload. Upgrading to the newest version now installs it.
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 had nothing to say about the newest version, because no advisory existed for a release published minutes earlier.
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. MAL-2025-6812 is not a CVE, and it does not become one.
The prefix separates two claims that call for opposite responses. CVE records say there is a defect in something you should keep using once it is patched, while MAL- records say 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.
One category has no record to find 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. Attackers who register one are 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. Scanners asked about it have 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
CVE feeds answer 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.
Whether you should have trusted the artifact at all is where the 2026 attack volume sits, and the controls for that question are different:
- 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
Aephix Vantage gives you a free view across ecosystems of what is already flagged as malicious, covering the category that CVE feeds exclude on purpose. Weekly Sleuth reports confirmed artifacts linked to the operation behind them, so blocking one compromised package blocks the publisher’s next release too. The next hijacked version will not have a CVE on the day it reaches your lockfile, but it may have a publisher whose other work is already on file.