8 Malicious npm Packages: Check Exposure Now

Short answer: Eight malicious npm packages were newly disclosed on September 7, 2026. Four carried a reactivated Shai-Hulud payload, while four impersonated AI coding tools and relayed provider keys, prompts, and code context to attacker-controlled services. If any affected package appears in your dependency tree or install history, stop using the system, rotate exposed credentials from a clean device, and rebuild rather than assuming that uninstalling the package is sufficient.

Which malicious npm packages were disclosed?

The GitHub Advisory Database published eight malware advisories between 12:30:29 UTC and 13:51:36 UTC on September 7, 2026. That is the original disclosure date, not the date of a later roundup. The year also matches the current year, so these advisories pass the breaking-news freshness check.

None of the eight advisories lists a patched version. GitHub says a machine that installed or ran the first four packages should be considered fully compromised. The feishu-docx-mcp advisory explicitly warns that package removal alone cannot guarantee that all resulting malware is gone.

What happened in the two npm malware clusters?

A dormant Shai-Hulud payload reappeared

The first cluster comprises feishu-docx-mcp, blueai-cli, bmc-i18n-extract-cli, and bmc-translate-utils. Aikido researchers reported that the four releases carried the same payload hash previously seen across hundreds of package versions on May 19, 2026. The hash then disappeared from new releases for 111 days before resurfacing on September 7.

This detail matters operationally: an old payload can reappear in a new package release. A clean scan last week does not prove that a newly resolved dependency is safe today. Teams should preserve lockfiles, review dependency changes, and apply controls at the install boundary instead of relying only on periodic repository scans.

AI coding CLI impersonators relayed sensitive data

The second cluster targets developers looking for AI coding assistants. GitHub describes orbitron-tui, orbitron-cli, agent-free, and prime-coding-agent as part of a coordinated campaign. The packages read LLM or provider API keys from environment variables or application configuration, then sent authenticated requests to attacker-controlled backends.

Those requests could expose more than a key. The orbitron-tui advisory says the relay received the authorization token together with chat prompts and code context. All 84 published orbitron-tui versions were affected. orbitron-cli@1.0.1 also linked itself to orbitron-tui through an update path, while agent-free@1.0.0 used the same backend as later orbitron-tui builds.

prime-coding-agent@3.10.6 used a different attacker-controlled backend but the same fundamental pattern: it forwarded provider credentials, prompts, and code instead of contacting the expected service directly. The primary GitHub advisory identifies the single published version as malicious.

How do you check whether your project is exposed?

Check direct dependencies, transitive dependencies, global tools, CI logs, container layers, and developer workstation history. A package may have been installed even if it was later removed from package.json.

1. Search the current dependency tree. Run npm ls --all and search the output for all eight package names. Repeat with the equivalent command if you use pnpm, Yarn, or Bun.
2. Inspect lockfiles. Search package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml, and Yarn lockfiles. Commit history can reveal a dependency that was installed and removed before the current revision.
3. Check global installations. Run npm ls -g --depth=0. AI coding CLIs are especially likely to have been installed globally rather than added to one repository.
4. Review CI and build logs. Look for installation of any affected name on runners, release machines, or container builds since the first version you may have resolved.
5. Scan package manifests across repositories. Search your source-control organization, monorepos, archived projects, templates, and automation scripts. Include agent configuration that invokes packages with npx.

You can also use InstallSafe's free npm package scan for an advisory-backed check. Treat a positive result as an incident-response trigger, not merely a dependency-maintenance ticket.

What should you do if you installed one?

1. Isolate the affected machine or runner. Stop builds and prevent further access to sensitive services.
2. Rotate credentials from a known-clean device. Prioritize LLM provider keys, npm tokens, GitHub tokens, cloud credentials, SSH keys, signing keys, and secrets available to the install or runtime process. Revoke old credentials before issuing replacements.
3. Review provider and service logs. Look for unfamiliar API calls, token use, source-control access, package publication, and cloud activity. Preserve evidence before rebuilding systems.
4. Remove the dependency from manifests and lockfiles. Because no patched versions exist, do not downgrade to another release within these package names.
5. Rebuild from a trusted baseline. GitHub's malware advisories warn that uninstalling a package is not proof of recovery. Reimage developer systems or replace ephemeral runners and rebuild containers from clean inputs.
6. Rescan and monitor. Confirm the package names are absent, validate newly issued credentials, and watch for follow-on access.

For a broader incident workflow, use our guide to detect and respond to malicious npm packages. Teams reviewing install behavior should also harden npm lifecycle scripts, while remembering that script blocking does not stop every malicious package or runtime data relay.

How does a registry firewall reduce the risk?

A registry firewall sits between package clients and the public registry. When an advisory feed flags a package version, the firewall can deny that version before its tarball reaches a workstation, CI runner, or autonomous coding agent. This moves enforcement from a warning after installation to a policy decision at the install boundary.

InstallSafe uses OSV.dev advisory data to identify known-bad versions and blocks flagged versions at the registry boundary. It can apply the same policy to developer installs, CI jobs, and AI agents, and delivers byte-for-byte registry tarballs for allowed packages. See the npm registry firewall guide for the architecture and rollout model.

No advisory-based firewall can promise zero-hour detection. There is an unavoidable interval between a malicious release and its addition to a trusted advisory database. Behavioral-analysis products may detect suspicious install or runtime activity before an advisory exists; registry policy is strongest when combined with release-age delays, lockfile review, least-privilege credentials, isolated builds, and behavioral monitoring.

Frequently asked questions

Are all versions of the eight packages malicious?

GitHub marks every published version of each package as affected. For four packages the range is >= 0; the AI CLI advisories identify all 84 orbitron-tui versions plus the single versions of orbitron-cli, agent-free, and prime-coding-agent.

Is there a safe version to upgrade to?

No. The advisories list no patched versions. Remove the package name entirely and replace the functionality only with a separately verified package or trusted source.

Is deleting node_modules enough?

No. Deleting dependencies prevents that copy from running again, but it does not revoke stolen credentials or remove persistence that malware may have created. Rotate secrets and rebuild affected systems from a trusted baseline.

What secrets should AI CLI users rotate?

Rotate every provider key, repository token, cloud credential, signing key, and other secret accessible to the CLI process. Review prompts and code context sent through the tool as potentially disclosed.

Will npm audit find these packages?

It may detect entries once the advisory data reaches the sources it consumes, but timing and database coverage vary. Search package names directly and use more than one control rather than relying on a single command.

Can a registry firewall block a malicious package immediately?

It can block a version as soon as the configured advisory source flags it. It cannot reliably block an unknown malicious release before any advisory exists, so combine it with behavioral monitoring and least-privilege build environments.