npm will scan every package for malware before publication, introducing the first mandatory delay in the registry's history

npm Now Screens Every Package for Malware Before It Goes Live

npm is introducing automatic malware scanning of all packages at publish time, meaning newly published packages will be unavailable for installation for roughly five to fifteen minutes while they are screened against detection systems. Flagged packages can be held for manual review or blocked entirely, with publishers able to appeal. The change also introduces a contentPolicy metadata field in package.json for declaring dual-use packages, which must be published with enforced two-factor authentication and a DISCLOSURE file explaining security-relevant functionality. Once dual-use metadata is declared, it cannot be removed in future versions. The shift from reactive post-publication detection to proactive screening at the point of publication marks the most significant supply-chain security change in npm's history.

npm has operated on one assumption since it launched: the moment you publish, your package is installable. That assumption ended on July 28, 2026. npm now screens every newly published package for malware before making it available, creating a mandatory wait of roughly 5 minutes that can stretch to 15 or more during peak periods 1.

This is not an opt-in security feature layered on top of the registry. It is a gate that every package must pass through.

How the scan works

After a publisher submits a package, it enters a screening queue. Depending on the results, the package is cleared for normal publication, held for manual review by npm's Trust and Safety team, or blocked 1. Blocked publishers may receive a notification with the option to appeal, and npm may take further action on the associated maintainer account depending on the severity and confidence of a finding 1.

While a package sits in the queue, the npm dist-tag command continues to function, but npm deprecate and npm unpublish are unavailable until the package clears screening 1. npm's guidance to publishers is explicit: any automation that assumes a package is installable immediately after publishing must be updated to tolerate a delay 1.

Dual-use packages get permanent obligations

The second half of this change targets a messier problem. Some legitimate packages contain code that looks like malware to automated scanners. For these, npm is introducing a contentPolicy field in package.json where maintainers can declare that their package has dual-use capabilities 1.

The declaration comes with three requirements. The package must be published with enforced two-factor authentication, satisfied through trusted publishing with OIDC, an interactive 2FA session, or staged publishing's built-in approval step 1. The maintainer must include a DISCLOSURE file in the package root, written in free-form text, explaining both the security-relevant functionality and its intended legitimate use 1. npm's Trust and Safety team reads these files during review, and the declaration may trigger additional automated scanning tailored to dual-use content 1.

The third requirement is the one developers should pay attention to: once a package is published with dual-use metadata, the declaration cannot be removed. Future versions that drop the contentPolicy field or the DISCLOSURE file will be rejected by the registry. npm says this requirement will be enforced progressively over time 1.

A maintainer who declares dual-use metadata today is committing every future version of that package to the same disclosure obligations, with no way back.

The attacks that built the case

The scanning program arrives after a year of escalating supply chain attacks targeting npm. In June 2026, researchers at Socket identified a campaign linked to the Mini Shai-Hulud malware family that compromised 23 npm packages, then pushed trojanized versions designed to steal developer secrets and CI/CD tokens 2. The compromised versions were published within seconds, underscoring why reactive takedowns fail when install pipelines pull new releases automatically 2. A separate incident tracked by Snyk in the same month compromised 57 packages through a self-propagating worm that abused the binding.gyp build file to execute malicious code at install time, harvesting credentials from npm, GitHub, AWS, and other services 3.

GitHub has documented a broader pattern of such attacks over the past year, describing campaigns that target weaknesses in package repositories to spread malware across hundreds of open source projects 4. The mandatory scan screens every package at the point of publication, before it can reach a single installer.

The tradeoff npm is making

npm has stopped being a passive conduit. For its entire existence, the registry's value proposition was immediacy: publish now, install now. The implicit trust was that malicious packages would be caught after publication by the community or by npm's takedown systems.

That model breaks when a compromised account can push trojanized code that pipelines pull within seconds. The cost of the new approach is friction. Every publish now carries a wait. Dual-use packages carry irreversible disclosure obligations.