Skip to content

Back to the catalog

NPM Implements Pre-Publication Malware Scanning, But Will It Work?
opensourcemalware.comarticle

NPM Implements Pre-Publication Malware Scanning, But Will It Work?

OpenSourceMalware analyzes npm's July 28, 2026 announcement of pre-publication malware scanning, contrasting it with GitHub's April 2026 admission that it already scans every published package version with human-in-the-loop review due to false-positive risk at scale. The author argues the promised five-minute publish-time SLA implies automated (not human-reviewed) blocking decisions, that the new package.json contentPolicy/DISCLOSURE dual-use mechanism is an admission of expected false positives that burdens legitimate security researchers rather than attackers, and that the five-minute budget limits detection to static/signature matching that will miss multi-stage payloads, dependency confusion, and DPRK tradecraft like the PolinRider campaign.

TL;DR Critical analysis argues npm's new publish-time malware scanning is the same old detection engine moved earlier in the pipeline, with a five-minute SLA that can't support the human review GitHub itself said was necessary, and a dual-use disclosure policy that mainly burdens honest researchers.
Document

What it is

An analysis of npm's July 28 publish-time malware scanning announcement, plus a walkthrough of the concrete behavioral changes it introduces for anyone who publishes to npm. The actionable content is the new publish mechanics and the contentPolicy dual-use declaration requirement — details the summary names but does not spell out.

How it works

Publishing now inserts a delay before a package becomes installable: about five minutes normally, stretching to 15 minutes or more at peak times or for larger packages. npm explicitly states these numbers "aren't a service guarantee." The scanner then publishes normally, holds for manual review, or blocks. If blocked, the publisher "may receive a notification with the option to appeal," and npm may also act against the maintainer account.

The author's core argument: this is not new detection. GitHub Principal Engineer Zachary Steindler wrote on April 1, 2026 that npm already scans every package version, that hundreds of malicious packages are detected daily, and that a human confirms each true positive because a 1% false-positive rate "would disrupt hundreds of legitimate publishes daily." The piece reads the ~5-minute delay as the tell that a human is still in the loop — the same engine, moved to the other side of the publish gate.

What to do

  • Fix CI that assumes instant availability. During the pending window, npm dist-tag still works, but npm deprecate and npm unpublish do not. Any pipeline that installs a package the instant npm publish returns is now broken.
  • If you ship dual-use content, add a contentPolicy field to package.json and a text-only DISCLOSURE file in the package root explaining the functionality and its legitimate use. Dual-use packages must be published through a method that enforces 2FA.
  • Treat the declaration as permanent. Once you declare contentPolicy, you can never remove it — new versions that drop the field or the DISCLOSURE file get rejected. npm says this is "progressively enforced" and that it is emailing dual-use maintainers directly so they aren't blocked by default.

Caveats

Per the author, the announcement (447 words) names no scanner, no start date, no partner, and no performance numbers. The mitigation is architectural — gating at publish gives a malicious package that never becomes installable a "blast radius of zero" — but the underlying engine's track record is the concern: Sonatype has logged ~1.8M malicious packages, with npm at 96.6% of Q2 2026's count, on a registry that was already scanning. The author notes thousands of researcher-reported malicious packages remain live. The fetched text cuts off mid-sentence in the "Five minutes is the tell" section.

Organisations named here

  • Greg Ose
  • IndonesianFoods
  • Shai-Hulud
  • Zachary Steindler

Technologies named here

  • NPM publish-time malware scanner
  • npm registry
  • GitHub/npm's existing post-publish malware scanner
  • npm CLI
  • Sonatype tracking/reporting
  • package.json
  • GitHub Actions
  • contentPolicy / DISCLOSURE mechanism
  • Dependabot cooldowns
  • Package firewalls
  • OpenSourceMalware
  • npm
  • GitHub
  • Dependabot
  • Sonatype

Techniques named here

  • Publish-first, catch-later malware distribution
  • Unobfuscated postinstall hooks that curl a payload
  • Typosquatting
  • Known IOC strings and C2 domains
  • Multi-stage loaders
  • Dependency confusion
  • Runtime triggers, geofencing, or delayed execution
  • Malicious repo artifacts outside the npm tarball

Threat actors named here

  • IndonesianFoods campaign
  • Shai-Hulud
  • Mini Shai-Hulud
  • Miasma
  • PolinRider
  • DPRK