npm's AI Severity Number Doesn't Mean What It Looks Like
By Beatriz Costa
In the first half of 2026, GitHub published 2,135 reviewed npm security advisories. On the surface, AI/LLM tooling looked like the safe corner of npm: 44.5% of AI advisories landed High or Critical, against 54.7% for everything else.
That should have been the headline. It isn't. One project explains almost the entire gap.
openclaw, a self-hosted AI agent gateway, accounts for 550 of npm's 710 AI advisories: 77% of the category. Pull it out of the average, and the remaining AI-positioned advisories jump to 65.0% High/Critical. Tighten the definition of "AI-native" further, and the number climbs to 70.2%.
So which number is real? Both are. They're just answering different questions: one about openclaw's audit, one about AI tooling in general. The rest of this post is about telling those two questions apart.
For defenders, the actual lesson isn't "watch out for openclaw," and it isn't "rank AI tooling by severity averages" either. It's where the bugs cluster: authorization, privilege boundaries, SSRF, command execution, path traversal, and the agent/tool interfaces that reach local files, shells, internal services, or automation workflows.
TL;DR
We analyzed 2,135 GitHub-reviewed npm advisories (OSV format) published between January and June 2026, withdrawn advisories excluded, a bigger dataset than the PyPI episode's 1,352.
Five findings:
Why the headline number is a trap
If AI advisories look less severe than the rest of npm, is AI tooling actually safer? No. The monthly breakdown is the first clue.
One caveat covers every table in this section: these are advisory publication dates, not the dates bugs were introduced or first exploited. A burst can mean a backlog clearing, not a wave of new bugs.
March and April look like a trend. They're not: they track openclaw's disclosure bursts almost exactly (more on that in the case study below). Here's the same series with openclaw removed:
The trend runs from 5 to 32, a 6.4x increase, directionally real, but on a thin base. Those 160 advisories come from only 5 remaining AI projects: n8n, flowise, @budibase/server, and two low-volume SDK advisories (@anthropic-ai/sdk, @langchain/community). PyPI's equivalent, minus PraisonAI, still had 20 distinct AI projects growing 2.9x. Take openclaw out of npm's story, and what's left rests on a much thinner base than PyPI's did. That's a real limitation of this episode, not a footnote to bury.
The severity paradox, and what actually explains it
This is the finding that would have shipped wrong if we'd stopped at the headline number.
Read the table top to bottom, and AI looks less severe. Read it bottom-up, stratify by the one project responsible for 77% of the category, and AI comes out 10 points higher in High/Critical share than everything else. Same direction PyPI showed (71% vs. 45%, from that episode's 1,352-advisory dataset, same category definitions).
So why does openclaw pull the average down, when it's the most authorization-concentrated project in this dataset, bug for bug?
Here's where we landed: openclaw is a self-hosted gateway people run on their own machine or server, not a multi-tenant hosted service. Several of its "moderate" and "low" findings say so explicitly. The debug-override prototype-pollution bug, for instance, is scored Low because it requires a caller who already holds debug-set authorization, with no unauthenticated path identified. Put the same bug class in a hosted multi-tenant agent framework, like open-webui or PraisonAI, and an ordinary authenticated user might be enough to reach it. In a self-hosted, single-operator deployment, that precondition usually isn't met.
That's our call, and we think the advisory text supports it well. It's not the only possible explanation, and we won't pretend otherwise: severity labels also reflect project-specific scoring choices and maintainer triage style, and the text alone can't fully separate that from the deployment-model story. But deployment model is the best-supported explanation we found, and it's the one we're going with.
To be clear about what excluding openclaw is not doing: we're not arguing it should be dropped from the dataset. Every number above still includes it. The ex-openclaw view exists because a category-level average is quietly answering two questions at once: what happened across npm's AI advisories, and what happened inside one project's unusually large, unusually thorough audit. Reporting both is more honest than picking one.
Sensitivity check. n8n and @budibase/server are judgment calls, older projects that repositioned around agentic AI in 2025-2026 rather than AI-native from the start (flagged in METHODOLOGY.md). Rerun the exclusion with a stricter AI-native allowlist (openclaw, flowise, and the two low-volume AI-native SDKs only), and the ex-openclaw severity rises further, to 70.2% (40 of 57 advisories). The direction of the finding doesn't move depending on how those two edge cases get classified. That's the check we'd want to see before trusting a severity claim, so we ran it before publishing rather than after someone asked why the number looked off.
Where the advisories concentrated
Quick note before the table: advisory volume is not a project-quality ranking. High counts can mean popularity, deployment model, exposed attack surface, audit depth, maintainer responsiveness, or disclosure maturity, sometimes all at once, and sometimes the good kind: a project audited thoroughly, disclosed transparently, patched publicly.
Top 15 npm packages by advisory count, H1 2026:
*AI-positioned: general-purpose automation platforms that added agentic-AI positioning in 2025-2026, a judgment call flagged in METHODOLOGY.md, not AI-native tools from the start like the AI-native rows above. See the sensitivity check above for the severity comparison rerun with these two excluded.
Same read as PyPI's ranking: AI-tagged packages hold #1, #2, #4, and #11 by count (three of the top four rows), and their bug profiles cluster on authorization and execution: path traversal, OS command injection, SSRF, IDOR, missing authz, rather than the classic XSS/SQLi profile that dominates many of the web rows. (n8n mixes in some classic XSS/SQLi too, the one AI-tagged package here that doesn't cleanly fit the authz-only pattern.)
CWE fingerprint by category
Two things worth flagging honestly. "Other" has the highest aggregate severity of the three groups (57.5%), a reversal from PyPI, where "Other" was the least severe category. And "Web" shows SQL injection in its top six for the first time in either episode; PyPI's Web fingerprint didn't have SQLi in its top six at all. npm's web-framework advisories genuinely carry more classic injection bugs than PyPI's did.
Case study: openclaw, another systematic audit
openclaw's 550 advisories didn't trickle in as scattered organic reports. They landed in bursts: 102 in a single day (March 3), plus stretches of 24 to 38 a day (Feb 17-18, Mar 26, Apr 3-17, Jun 18). PraisonAI showed the same pattern on PyPI, at smaller scale: 38 in a day, versus openclaw's 102. The burst timing, the repeated structure across advisories, and the precision of the affected-version ranges point to a systematic, likely tool-assisted audit, not database noise. 429 of 550 (78%) carry a CVE, with exact fix commits and precise technical descriptions in the ones we read closely.
What did that audit actually find? A Windows Scheduled Task generator that could emit unescaped cmd metacharacters. An X-Forwarded-For parser that trusted spoofable headers behind a proxy chain for security decisions. A gateway reconnect flow that let a non-admin operator self-claim operator.admin scope (Critical). A debug-override path that accepted __proto__/constructor keys (Low, gated behind an already-authorized caller).
That spread, from Critical down to Low, inside one project and one audit, is itself the lesson. A thorough audit surfaces a bug class's whole severity distribution, not just its worst instance. Judge a project's risk by its average severity instead of its bug-class fingerprint, and you undersell it.
Worth saying plainly: this isn't an argument that openclaw is uniquely bad, or that defenders should avoid open-source agent tooling. If anything, the opposite lesson holds. Public advisories, precise version ranges, and fixed versions are what a security process working in the open looks like. 541 of openclaw's 550 advisories (98.4%) carry a fixed version, evidence of maintainers responding at real scale, not proof that every issue is closed.
The broader pattern: once a popular agent framework becomes the target of a systematic audit, its authorization surface gets enumerated fast and broadly. Expect more agent frameworks to get the openclaw treatment as more teams put them into production, and expect the response to matter more than the raw count.
Beyond openclaw: the rest of npm's AI tooling
Three other AI-positioned projects show overlapping authorization or execution-boundary failures independently of openclaw, which is better evidence that this isn't a one-project artifact.
Worth being precise about "AI-positioned" here: n8n and @budibase/server are general automation platforms that adopted AI/agent positioning in 2025-2026. Not every bug below lives in an AI/agent-specific surface. flowise's MCP-adapter and Airtable-agent bugs do, n8n's Merge-node SQL bug arguably doesn't. The pattern is about what fails across AI-positioned tooling broadly, not a claim that every bug is itself "an AI bug."
n8n (83 advisories, 55.4% High/Crit): now explicitly positioned around AI agents and multi-agent orchestration, layered on its original workflow-automation core. Its bug profile is the most mixed of the four, real XSS and SQL injection alongside prototype pollution, closer to a traditional web app than a pure agent framework. Worth watching whether that profile converges toward openclaw's as its AI-agent surface grows relative to the original core.
flowise (53 advisories, 75.5% High/Crit): npm's counterpart to PyPI's langflow, a visual LLM/agent flow builder. Its top CWEs (prototype pollution, IDOR, SSRF) map closely onto langflow's own profile from the PyPI episode.
@budibase/server (20 advisories, 90.0% High/Crit): the highest severity rate of any package in this dataset. Budibase now positions itself around an "AI-powered workflow toolkit" for building agents and internal apps, and its bugs (SSRF, OS command injection, missing authorization) sit squarely in the execution/authz pattern this series keeps finding.
"Are these real, or is someone padding the count?"
Same challenge the PyPI episode had to answer, applied here. We checked structural provenance across all 710 AI-tagged advisories instead of trusting the labels, then checked a control group so AI isn't graded on a curve.
AI-tagged (710 advisories): 98.6% declare a fixed version, 100% carry a vendor-advisory link and a description over 200 characters, 0% lack all three of {fixed version, fix commit, vendor advisory}, stronger than PyPI's already-strong 1.9% floor.
One methodology note worth including rather than hiding: a strict OSV-schema check (reference type literally equal to FIX/ADVISORY) initially flagged 6 openclaw advisories as "provenance-free," two of them Critical. Reading them showed every one had an exact fix commit and a GitHub Security Advisory link, just filed under the generic WEB reference type instead of FIX/ADVISORY. A labeling quirk, not a data-quality gap. But exactly the kind of thing a script-only check would misreport if nobody reads the "failures" before publishing a number.
Control group, Web-tagged (201 advisories): 90.5% fixed version, 100% vendor-advisory link and description length, 0% lack all three, 96.0% carry a CVE (higher than AI's 80.1%), consistent with the coverage-gap finding below and confirmation both sides of the comparison are held to the same standard.
The cases carrying the thesis read as concrete and exploitable, matching the rigor the PyPI sample showed:
So the asymmetry in this episode, like PyPI's, isn't a labeling artifact. These examples are concrete and well-documented. Several reach RCE. At least two, @budibase/server's CVE-2026-35216 and flowise's CVE-2026-41265, are unauthenticated. That's not a claim that most AI advisories are unauthenticated RCEs. It's that AI-agent tooling repeatedly fails at authorization and execution boundaries, not that every instance is maximally severe.
The severity paradox is real, and deployment model is the best-supported explanation we found for it, not evidence that the underlying bugs are softer. We can't fully rule out project-specific scoring or triage style as a contributing factor, but we don't think it's carrying the weight of this result.
The coverage gap
Of 2,135 npm advisories, 335 (15.7%) carry no CVE identifier, slightly higher than PyPI's 12%. AI clusters here too, though less sharply than on PyPI: 19.9% of AI advisories have no CVE (141 of 710) versus 13.6% of everything else (194 of 1,425): about 1.5x, versus roughly 2x on PyPI.
This is exactly the population Safety's database is built to track, CVE or not. More on that below.
How does this compare to the PyPI episode
How this compares to the PyPI episode
The open question going into this episode was whether the authorization/execution pattern generalizes across ecosystems. It does, and npm's biggest AI project is, if anything, more concentrated on authorization bugs than PyPI's was.
The "one dominant project" pattern generalizes too. Both ecosystems' AI narratives lean on a single, systematically audited project: PraisonAI at 8.9% of all PyPI advisories, openclaw at 25.8% of all npm advisories, an even larger share.
Severity comparisons don't generalize without a robustness check. PyPI's AI-severity finding held up on the first read. npm's inverted until we excluded the dominant project. Run this check before publishing a severity claim, on either ecosystem, not after someone asks why the number looks off.
The AI project roster is much thinner on npm (6 distinct projects total, 5 excluding openclaw) than PyPI's 21 (20 excluding PraisonAI). Read npm's trend numbers with that in mind: a thin roster means next episode's numbers can swing hard on the timing of one or two projects' disclosures.
What this means for your team
How Safety helps
Everything above came from the public GHSA dataset, measured in the open. That part doesn't need a sales pitch. But it's also why CVE-only tooling misses more than it should: 15.7% of npm advisories in this dataset, and 19.9% of AI-tagged ones, are GHSA-only. A workflow that only ingests CVE-numbered records wouldn't have surfaced them at this snapshot, unless or until a CVE showed up later. Safety tracks CVE and non-CVE vulnerability records, including GHSA-only advisories with no CVE at the time of this snapshot: exactly the population this analysis shows clustering more heavily in AI/LLM tooling, on npm and on PyPI both.
Coverage is only half the problem. The other half is noise. Knowing a package has a vulnerability doesn't tell you whether your code ever touches the broken part of it. Where function-level data is available on Safety, you get visibility into the specific functions a vulnerability affects, so instead of triaging by package name alone, you can check whether the vulnerable function is one your code actually calls.
There's also a layer this whole analysis doesn't touch: what's already sitting on your developers' machines. Advisory data tells you which packages are vulnerable. It says nothing about the AI tool, MCP server, or IDE extension somebody pulled onto a laptop last Tuesday, outside any lockfile or dependency manifest. Endpoint detection and device management were built before coding agents existed, so none of them sees that workstation layer either. Safety does: agentless, deployed via MDM, no developer buy-in required, so it doesn't depend on someone remembering to ask permission before installing the next MCP server.
Get started for free: scan your dependencies for CVE and non-CVE vulnerability records in about a minute.