59 Malicious npm Packages Disclosed Overnight

Short answer: GitHub published malware advisories for 59 malicious npm packages between September 5 at 19:26 UTC and September 6 at 03:58 UTC. GitHub marks every version of every named package as affected and advises treating computers that installed or ran them as fully compromised.

The original disclosures are from 2026 and were less than 11 hours old at our September 6, 06:00 UTC check. This is a current advisory batch, not a resurfaced report about an older npm attack. The public advisories do not describe the payloads in detail, so this guide sticks to what developers can verify and do safely.

Which malicious npm packages are affected?

The affected range in each GitHub Advisory Database record is >= 0, meaning all published versions of the following packages should be treated as malicious. There is no patched version to upgrade to.

E-commerce SDK lookalikes and other packages disclosed September 6

• @liuliang520500/sinataoke_cn_test
• @liuliang520500/sinataoke_cn
• @liuliang520500/pdd-sdk-new
• @liuliang520500/pdd-sdk
• @liuliang520500/jd-sdk
• @liuliang520500/taobao-topclient
• @pilllesss/yorn
• dcftunnel
• 1cattunnel
• multicore-kit
• date-fns-formatter
• array-frames
• node-helper
• jwt-logger
• array-scala

DOM, image, utility, and media-themed packages

• @domyjs/i18n, @domyjs/reactive, @domyjs/router, @domyjs/mask, @domyjs/throttle, @domyjs/intersect, @domyjs/domy, @domyjs/debounce, @domyjs/anchor, and @domyjs/collapse
• @yoannchb/wtf-json, @yoannchb/tokenize, @yoannchb/langy, and @yoannchb/cattract
• enqueu, puppeteer-obscura, inner-svg-ts, pipipe, chrome-speech-recognition, drive-album, card3d, parallaxy-img, iframe-to-video, and jimg
• tempjs-template, memov, muswish, btn-particles, onetime-rnd, google-img-scrap, json-into-html, fast-html-dom-parser, and lazy-attr
• discord-tqr, anime-vostfr, infinity-grid, discord-phub, and linkpreview-simple

Cryptocurrency-themed packages

• trading-bot-utils
• eth-query-utils
• ens-namehash-utils
• gas-price-checker
• wallet-watcher
• eth-lib-helpers

The authoritative records include GHSA-36jr-wqjh-q55x for the latest disclosure, GHSA-rpqx-cp2g-55w5 for jwt-logger, and GHSA-2h3c-rw6j-mpq7 for the first record in the verified disclosure window.

How can I check whether my project is exposed?

Check both direct and transitive dependencies. A package can appear in a lockfile even when nobody added it directly to package.json.

1. Search repository manifests and lockfiles. Search package.json, package-lock.json, npm-shrinkwrap.json, yarn.lock, and pnpm-lock.yaml for every package name above.
2. Inspect the installed dependency tree. Run npm ls <package-name> --all for any match. Repeat with the relevant workspace root if you use npm workspaces.
3. Check build and deployment history. Search CI logs, container build logs, dependency update pull requests, artifact manifests, software bills of materials, and private-registry download logs.
4. Check developer machines and caches. A package may have executed during an earlier install even if a later lockfile removed it. Review package-manager caches, shell history, endpoint telemetry, and recent node_modules trees according to your incident-response policy.
5. Scan without installing. InstallSafe's free npm package scanner checks a package version against OSV.dev advisory data without asking you to execute it.

For a reusable pre-install checklist, see how to check if an npm package is safe. Our broader malicious npm package detection and response guide covers lifecycle scripts, dependency confusion, typosquatting, and post-install containment.

What should I do if I find one?

Do not treat this as an ordinary vulnerable-library upgrade. GitHub's malware advisories say that any computer with one of these packages installed or running should be considered fully compromised.

1. Isolate the affected system. Stop using the machine or runner for trusted builds and prevent further outbound access where your response process allows it.
2. Preserve evidence. Capture relevant logs, process data, network telemetry, affected lockfiles, and artifacts before cleanup. Coordinate with your security team instead of deleting evidence ad hoc.
3. Remove the malicious dependency. Delete it from manifests and lockfiles, then rebuild the dependency tree from a known-good source. There is no safe version listed for these package names.
4. Rotate reachable secrets from a clean computer. Prioritize npm tokens, GitHub tokens, cloud keys, CI credentials, SSH keys, signing keys, database credentials, and wallet secrets that were present while the package could have run.
5. Rebuild from a trusted baseline. Reimage affected developer systems or replace disposable CI runners. Rebuild containers and browser bundles, purge suspect registry caches, and redeploy clean artifacts.
6. Hunt for follow-on access. Review account activity, new access keys, workflow changes, package publications, persistence mechanisms, and unusual outbound traffic.

Simply deleting node_modules is not enough when the advisory says full system compromise is possible. A malicious install script or imported module may already have exposed credentials or created persistence outside the project directory.

How does a registry firewall help with malicious npm packages?

A registry firewall sits on the dependency download path. When a requested package version is already flagged in the firewall's advisory source, it can deny the tarball before npm, CI, or an AI coding agent installs it. That gives teams one policy boundary across laptops, build systems, and autonomous tools.

InstallSafe uses OSV.dev advisory data to block flagged versions at the registry boundary, serves byte-for-byte upstream tarballs for allowed versions, and applies the same decision in local development, CI, and agent-driven installs. See the npm registry firewall architecture guide for deployment patterns.

The limitation matters: an advisory-backed firewall cannot block a truly zero-hour package before its data source identifies it. Behavioral-analysis tools can sometimes flag suspicious install scripts, obfuscation, or network behavior earlier. Strong programs combine package identity controls, lockfile review, least-privilege CI, behavioral inspection, endpoint monitoring, and an install-boundary firewall.

What do the advisories confirm—and what remains unknown?

GitHub confirms that the 59 named packages contain malware, marks every version as affected, lists no patched releases, and recommends full-compromise response. The records were originally published between September 5, 2026 at 19:26 UTC and September 6, 2026 at 03:58 UTC.

The public records do not currently explain which files or scripts execute, what data may be collected, which command-and-control infrastructure is used, or whether all 59 packages share one operator. Similar publication times and naming patterns are useful for triage, but they are not proof of a single campaign. Defenders should avoid inventing payload claims and use the advisory's conservative full-compromise guidance.

FAQ

Are only specific versions affected?

No. Each GitHub advisory lists the affected range as >= 0, so every published version under each package name should be treated as malicious.

Can I upgrade to a fixed version?

No patched versions are listed. Remove the package and replace the functionality with a verified dependency or internal implementation after security review.

Does npm audit find these packages?

Detection depends on advisory propagation and the tool's data source. Search manifests and lockfiles directly, consult the primary GitHub advisories, and use a scanner that checks malicious-package records—not only CVEs.

Am I safe if the package was only in a lockfile?

A lockfile match proves dependency resolution, not execution. Check whether installs or builds occurred on developer machines, CI runners, containers, or deployment systems during the relevant period.

Should I rotate secrets if the install failed?

If the package began installing or running, assume reachable secrets may have been exposed. Rotate them from a clean system according to your incident-response plan.

Can a registry firewall prevent every malicious package?

No. It can block versions after its advisory source flags them. Pair registry controls with behavioral analysis, constrained lifecycle scripts, least-privilege credentials, reproducible builds, and monitoring.