Malware researcher access to removed malicious NPMs

[ryanlrussell]

Select Topic Area

Question

Body

Question inspired by the recent S1gularity, Chalk etc., and Shai-Hulud events, where NPM packages had malicious code included.

The malicious versions were removed quickly from the live registry in order to reduce impact. Which is great, and as it should be.

I'm requesting a mechanism for malware researchers to be able to access the removed NPMs. Does such a mechanism already exist? And if not, could that be done as part of the removal process? If it would be created from scratch, it should be authenticated access (so that anonymous access is not available, which would otherwise make it another malware hosting mechanism). Possibly with vetted access, if desired. Example: authenticated access to a quarantine portion of the registry.

Alternately, existing malware sample repository sites exist, such as Malware Bazaar, Hybrid Analysis, and VX Underground. Samples could simply be uploaded to those.

[Wealthometer]

What does already exist

npm-follower / dependencies.science
This is a research dataset that archives code + metadata of all versions of npm packages as they get published — including the ones that are later deleted or unpublished.
arXiv
+1

For example: Between July 2022 and May 2023, over 330,000 versions of packages were deleted from the live npm registry, but npm-follower had already archived ~281,858 of those deleted versions.
2023.esec-fse.org

Pros: Researchers can access removed/ deleted code.
Cons: It’s a public dataset, so there’s no access control / quarantine; malicious versions are publicly available once archived. Also, it's retrospective: versions must have been scraped / archived before deletion.

npm’s unpublish policy & deprecation tools
npm allows unpublishing of package versions (or entire packages) under certain criteria (e.g. no dependents, low downloads, “less than 72 hours” window for newer versions)
npm Docs
+1
.
They also allow deprecating versions so users see warnings, rather than full “delete.”
npm Docs

Limitations / Gaps

No authenticated / controlled access to removed versions
While datasets like dependencies.science have these removed versions, they are publicly available. That could be abused (e.g. hosting malware, etc.). There's no built-in “quarantine” by npm that gives researchers special access to versions removed for being malicious, but hidden to general public.

Latency & completeness
If a malicious version is published and quickly removed, and researchers didn’t have archiving in place before removal, they may have no copy. Real-time capture is tough.

Policy constraints
npm’s policies on unpublishing (downloads, dependents, time windows) limit whether maintainers can remove malicious versions themselves or whether npm support must intervene. That suggests that removal is messy and not always automatic.
npm Docs
+2
npm Docs
+2

Potential legal / security / liability issues
Hosting malicious code even for research poses risk. Also, npm (or GitHub / Microsoft) might have concerns about allowing anyone access to quarantined malicious code (e.g. someone might use it for bad). So there are compliance / policy / risk boundaries.

What a good mechanism could look like

Here’s a sketch for how I think a “quarantine + authenticated researcher access” mechanism could work (so we’re not just talking hypotheticals):

Definition of “malicious version”
There would need to be a clear, ideally automated or at least manual + verified, trigger for “this version is known or strongly suspected to be malicious” (e.g. someone reports, security firm confirms, etc.).

Quarantine storage
Once flagged, the version (tarball, metadata) is moved to a quarantined area. Regular users cannot install / fetch it via normal npm registry or CLI.

Authenticated / Vetted researcher access
Researchers / malware analysts can apply for access. The registry owners (npm, GitHub, or a third party) would grant read-only access to the quarantined artifacts. Could require things like data use agreement, proof of affiliation, etc.

Audit & logging
Every access is logged. Maybe even restricted by purpose.

Retention policy / legal guardrails
Because storing and distributing known malicious code has risks (even if only for research), there should be controls on retention, who can access, and maybe some cleaning of extremely dangerous payloads (e.g. large malware payloads).

Integration with existing datasets
The archived versions in something like npm-follower could be supplemented or integrated with the quarantine system, so that when a malicious version is removed, the archived version is flagged, possibly reclassified, and maybe optional withholding of immediate public visibility until vetted.

Does npm or any registry plan something like this?

As far as public info goes: I haven’t seen npm formally announce a quarantine + authenticated researcher portal for removed/malicious packages. The public dataset (npm-follower) is the closest existing thing. There are community or researcher tools, but they don’t provide controlled access to malicious code only for vetted parties.

My take: Should this be done (and can it be)?

Yes, I strongly think it's worthwhile. These supply chain attacks are getting more frequent, so having a controlled, trustworthy way for researchers to examine malicious versions (after removal) helps with faster detection, signature creation, remediation, etc.

It can be done. Npm (or whichever registry) has the technical ability: storing tarballs + metadata, access control, etc. The harder parts are policy, legal, risk, and who vets researchers. But those are solvable with proper governance.

[ryanlrussell]

(Not sure if human using AI, or someone's bot directly using AI to answer, but:) Thanks for the pointers. It looks like a project like that would potentially solve at least partially what I am asking for. However, that particular one appears to have been a one-time effort, and the site where the data used to live is no longer up. Copies of the paper that was written are all over the place, though.

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬