36 npm packages from asteroiddao: what our scanner found.

The signal: a publisher burst

The first indicator wasn't a single suspicious package — it was the shape of the publish activity. Twenty-two packages from one publisher, all flagged high-risk, within the first two minutes (01:05–01:07 UTC). This coordinated mass-publish shape — what we call a “clob-dropper” — is a campaign fingerprint independent of any individual package's content. Our burst detector fires when five or more high-risk packages from a single publisher appear within ten minutes. This campaign tripped it immediately.

For context: OSV advisories for these packages appeared at 00:59 UTC, six minutes before our scanner processed them. This campaign was not a case where we led public disclosure — it's a case where both OSV and PkgRadar identified the threat within minutes of each other, and our static findings independently corroborate the advisory conclusions with specific artifact evidence.

Selected affected releases

The full campaign covers 36 packages including aonote, wdb-sdk, atomic-notes, ai3, wdb-cli, cwao-tools, weavedb-tools, create-arnext-app, weavedb-exm-sdk, roidjs, arnext, and others. View the full publisher history at the asteroiddao publisher page.

What the scanner found

Three packages drove the highest scores through behavioral findings. The remainder were elevated by the publisher-burst correlation — their individual content scores were lower, but the mass-publish context raises the threat model for the entire publisher account.

Why the lifecycle diff matters

The highest-confidence finding across this campaign is new_lifecycle_script_vs_previous. This isn't a static string match against the current release — it diffs the new version against the last known-good version and flags when an install-time script appears that wasn't there before.

Legitimate packages rarely add preinstall scripts in patch releases. When one appears in [email protected] invoking ./bin/install-deps and that script was absent in 0.0.1, the finding fires at High severity. The structural change is the signal. We make no claims about what that script does at runtime — that is outside the scope of static analysis.

[email protected]'s postinstall appends || true, which means the script's exit code is suppressed — npm install completes regardless of whether the script succeeds or errors. This pattern fires its own finding independently.

What you should do

• If any of these packages appear in a package-lock.json: review the OSV advisories for each affected package — they contain the reporter's analysis of runtime behavior, which is outside the scope of what we can determine from static analysis alone.
• Audit preinstall and postinstall hooks. Run npm ls and inspect the scripts section of every package.json in node_modules. Any lifecycle hook you didn't explicitly expect is worth reviewing — especially hooks that appeared in a recent version and weren't present before.
• Gate installs in CI. A PkgRadar CI gate set to fail_on=high would have blocked every release in this campaign at install time, before any advisory existed.

A note on post-hoc inspection

Two of the three highest-scoring packages — [email protected] and [email protected] — have since been removed from the npm registry (HTTP 404). Their tarballs are no longer retrievable, which means the scripts and binaries they shipped can no longer be inspected. This is a recurring pattern in supply-chain campaigns: by the time a package is publicly flagged and removed, the artifact evidence is gone. Scanning at publish time — before removal — is the only reliable window.

Detection timeline

OSV advisories for these packages first appeared at 00:59 UTC. PkgRadar's scanner processed and classified them starting at 01:05 UTC — six minutes later. Both systems identified the campaign within minutes of each other, working independently: OSV via reporter submission, PkgRadar via static artifact analysis on the npm changes feed.

The value of the static-evidence approach here is corroboration: the findings below (lifecycle diffs, binary exec hooks, failure suppression, known-indicator filenames) are derived entirely from the published tarballs, with no reporter in the loop. A CI gate checking PkgRadar at install time would have blocked these packages automatically, independently of whether an OSV advisory existed.

References

• Publisher posture: asteroiddao
• Previous campaign report: clob dropper (npm, May 2026)
• Detection methodology: how PkgRadar maps to SOC 2, NIST SSDF, ISO 27001, EU CRA