12 Flagged npm Packages OSV Doesn't List, and About 11,000 We Were Under-Blocking Ourselves: Where We Are Tonight
This is a work in progress, published on purpose before it is finished. Tonight we are blocking 8 npm packages that the open-source vulnerability database OSV does not list, we found a bug in our own deny-list that left roughly 11,000 known-malicious npm entries under-blocked, and a re-sync to fix it is still running. The real numbers replace the estimates here tomorrow.
What we found, and who found it first
None of these packages were our discovery. Elastic Security Labs (Jia Yu Chan and Daniel Stepanic) published REF8801 on October 12, naming @apexacc/cli as part of a fake Web3 accelerator. OX Security published "PhantomSub" on September 28, naming Baileys WhatsApp-library forks that silently subscribe the user's WhatsApp account to a channel the package author picks. Read Elastic's REF8801 report and OX's PhantomSub write-up first.
What we did was check whether they were still live. They were. @apexacc/cli is still on npm, latest version 1.6.2. Eleven of the Baileys forks are still on npm. The biggest, ourin-baileys, pulls about 7,600 downloads a week; the eleven together pull about 12,500. None of the twelve had an active OSV record when we checked.
Seven confirmed, four held out
We read the published code of all eleven forks without running it. In 7, there is a channel ID wired to fire when the library connects, hardcoded or decoded at runtime. That is the behavior OX described, and those 7 are blocked. Correction, 23:30 UTC: this post first said 8 and 9. A deeper hunt showed that in saurustheking the hardcoded channel ID only labels forwarded messages and is not wired to a follow, so we removed it from our deny-list and from our OpenSSF filing. The diagram below still shows the earlier count of 9.
The other 3 (neuralwhatsapp, fixo-baileys and sauruskyah-baileys) carry channel-follow code that upstream Baileys also has, and we could not confirm a target. So we do not block them. We briefly did, because our check blocks on any deny-list entry regardless of confidence, and we removed them tonight.
This morning our check-package said ALLOW for every one of the forks. Tonight it blocks @apexacc/cli and the 7 confirmed forks.
The correction we made on ourselves
Earlier today I said the Apex package disables Windows Defender and Smart App Control. Re-reading the code showed the commands are broken by unescaped backslashes in versions 1.5.122 through 1.6.2. Working versions existed in 1.5.120 and 1.5.121. We corrected it everywhere the same hour and shared the finding with Elastic. The full read is in our post on the backslash bug.
Our own miss
This is the part that stung. Our deny-list stored only the versions OSV listed at the moment we synced. When our matching logic improved, the sync never went back and rewrote the records it already had. So a newer version of a known-malicious package got "review" instead of "block."
How big is it? From a seeded sample of 500 records (369 of them npm), we estimate that about 43% of our version-limited npm records are listed in OSV as all versions malicious. That projects to roughly 11,200 entries. That is a projection, not a count. A verified re-sync of 35,541 candidates is running now at about 230 a minute and should finish around 01:15 UTC.
Two honest limits. "Review" is a warning, not an allow. And how many callers actually received "review" on one of these packages is UNKNOWN until we count it.
The root cause is fixed: every record now carries a logic-version stamp, so future fixes reach stored records instead of only new ones. An earlier commit of ours claimed daily syncs would clean this up on their own. That claim was wrong.
What shipped today
We reported @apexacc/cli to npm security, followed by a same-day correction. We opened two pull requests to OpenSSF's malicious-packages repository: #1644 covers @apexacc/cli and @apexacc/audit, and #1645 covers 7 of the forks. We left chromestaff-baileys out of #1645 because OpenSSF already has a withdrawn record for it, MAL-2026-4519, and we asked the maintainers to reinstate it. Filed, not merged.
Our free GitHub Action, DugganUSA Checks, got its v1.0.1 release tonight. On a real test pull request it failed the build that added @apexacc/[email protected] and let left-pad through. It is new. Zero repositories have adopted it so far. The thinking behind it is in We Watched, Then We Built the Membrane.
What comes tomorrow
Three things. The final re-sync count, replacing the 11,200 projection. The exposure count: how many check-package answers came back "review" on a package that should have been "block." And the family hunt: whether the 8 confirmed forks have siblings we have not found yet.
We checked 24 claims in this post against today's records and corrected 3 before publishing. At least 5% of what remains is still wrong, and we don't know which.
If this was useful, or if it wasn't, rate it at the bottom of the page. It is the only direct signal we get.
How do AI models see YOUR brand?
AIPM has audited 250+ domains. 15 seconds. Free while still in beta.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=12-flagged-npm-packages-osv-doesn-t-list-and-about-11-000-we-were-under-blocking-ourselves-where-w
Comments