5 Malicious npm Packages Disclosed September 7

Short answer: Five malicious npm packages were newly disclosed on September 7, 2026: vishal_312pkg, agentrc-security-poc-policy, omni-channel-configurator-wireline-frontend, b2b-frontend-external-library, and @caliperx2/components. Two execute commands associated with malicious behavior; the other three are dependency-confusion packages that collect host details during preinstall and send them to remote infrastructure. If any affected package ran, remove it, isolate the host, review outbound traffic, and rotate exposed credentials from a clean system.

Which malicious npm packages and versions are affected?

The GitHub Advisory Database published the five primary records between 06:30:26 and 06:30:27 UTC on September 7, 2026. That is the original disclosure date, not the date of a later report. The year matches the current year, 2026, and the records were less than 12 hours old when verified, so they pass the freshness check.

No advisory lists a safe replacement release. Do not assume that installing a newer version under the same name is remediation. Remove the package and replace it only with a dependency whose identity, owner, source repository, and expected namespace you have independently verified.

What do the September 7 npm advisories say?

Two packages execute commands associated with malicious behavior

OpenSSF Package Analysis identified vishal_312pkg@1.0.0 and agentrc-security-poc-policy@1.0.0 as malicious because they execute one or more commands associated with malicious behavior. The public records do not describe those commands, name infrastructure, or establish credential theft or persistence. Treat command execution as the verified fact and avoid guessing at capabilities the evidence does not support.

That limited public detail does not make the packages safe. Code that runs during installation or import inherits the permissions, readable files, environment variables, network access, and credentials available to the npm process. A developer laptop, CI runner, container build, or AI coding-agent sandbox may expose very different data, so response scope should follow where the package actually executed.

Three dependency-confusion packages beacon host details

omni-channel-configurator-wireline-frontend, b2b-frontend-external-library, and @caliperx2/components copy names that appear intended to collide with private internal dependencies. If a build resolves the public package instead of the intended private one, npm runs a malicious preinstall.js before a developer has a chance to inspect the installed files.

The advisories say the scripts collect the hostname, username, current directory, install directory, package name and version, operating system, Node.js version, and npm user-agent. They then send the data through DNS and HTTP to attacker-controlled infrastructure. The documented network indicators include subdomains of oast.online and HTTP traffic to 5.189.159.252. Even if comments describe the activity as research or bug-bounty testing, silent install-time collection and transmission is unwanted behavior and should be handled as an exposure.

This is a dependency-confusion pattern, not evidence that the organizations suggested by a package name were breached. A public package can target a guessed private name without compromising the real company, private registry, or legitimate internal codebase.

How can you check whether your project is exposed?

Check manifests, every lockfile, the resolved dependency tree, build logs, cached artifacts, and container layers. A package may be transitive or may have appeared only in an earlier CI run, so a clean working tree today is not enough.

1. Search manifests and lockfiles

rg -n 'vishal_312pkg|agentrc-security-poc-policy|omni-channel-configurator-wireline-frontend|b2b-frontend-external-library|@caliperx2/components' \
  package.json package-lock.json npm-shrinkwrap.json yarn.lock pnpm-lock.yaml

Run the search at the monorepo root and in archived release branches. Also inspect dependency update pull requests and lockfile diffs from September 7. For private packages, check whether manifests use an unscoped name that could resolve from the public registry or whether the expected scope is mapped to the correct private registry.

2. Inspect the installed dependency tree

npm ls vishal_312pkg agentrc-security-poc-policy \
  omni-channel-configurator-wireline-frontend \
  b2b-frontend-external-library @caliperx2/components --all

An empty current tree does not rule out past execution. Search retained CI logs for the package names and for lifecycle-script output. Review npm caches, reusable build caches, base images, deployment artifacts, software bills of materials, and any agent workspace that can run package-manager commands.

3. Review network and execution evidence

For the three dependency-confusion packages, search DNS, proxy, firewall, and endpoint telemetry for oast.online and 5.189.159.252. Correlate hits with npm, Node.js, shell, CI, and container-build processes. Preserve relevant logs before cleaning the host. For the two packages with command-execution findings, inspect process trees and outbound connections around the install or first-import time rather than inventing narrower indicators.

4. Identify credentials the process could read

Inventory the secrets available to the affected process: npm tokens, GitHub tokens, cloud credentials, deployment keys, package-registry credentials, SSH material, environment files, and CI secrets. Exposure depends on execution context. A lockfile entry without installation is different from a lifecycle script that ran on a privileged release runner.

What should affected developers do now?

1. Stop the affected job and isolate the host. Prevent further network access while preserving evidence. Do not continue using a potentially compromised runner for releases.
2. Remove the package and lockfile entry. Delete it from direct dependencies and regenerate the lockfile from a known-good commit using a clean environment. Confirm why it was introduced.
3. Invalidate caches and rebuild. Discard dependency caches, container layers, build artifacts, and reusable images created while the package was present.
4. Rotate reachable credentials from another trusted system. Revoke first, then replace. Prioritize npm, source-control, cloud, signing, and deployment credentials available to the affected process.
5. Review account and infrastructure activity. Look for unfamiliar package publications, repository changes, workflow edits, cloud sessions, deployments, and secret use after the suspected execution time.
6. Fix dependency resolution. Map private scopes explicitly, prevent fallback to the public registry for internal names, and reserve or rename ambiguous internal package names where appropriate.

Uninstalling alone is not a complete incident response because commands or lifecycle scripts may already have run outside node_modules. The broader malicious npm packages response guide covers containment and recovery in more detail. Teams should also review their npm install-script policy, while remembering that disabling scripts does not prevent malicious code from running later when imported.

How does a registry firewall help?

A registry firewall sits on the package download path. When a developer, CI job, or AI coding agent requests a version already flagged by the firewall's advisory source, it can block delivery before npm downloads and executes that tarball. This creates one control point for environments that may not consistently run a separate scanner.

InstallSafe uses OSV.dev advisory data to block flagged package versions at the registry boundary. It serves allowed tarballs byte for byte and can cover developer machines, CI, and agents that use the configured registry. You can run the free dependency scan first, then use the npm registry firewall guide to plan enforcement.

A registry firewall is not a zero-hour behavioral detector. It can block these packages after the advisories enter its data source; it cannot promise to recognize an undisclosed malicious release. Pair registry enforcement with scoped private registries, lockfile review, least-privilege CI, restricted egress, short-lived credentials, and behavioral analysis where the risk justifies it.

Frequently asked questions

Were all versions of these five npm packages affected?

GitHub lists 1.0.0 as affected for vishal_312pkg and agentrc-security-poc-policy. It lists all positive versions for the other three packages. None has a patched version.

Does a lockfile match prove the malware executed?

No. It proves the affected package was resolved into the dependency graph. Check install logs, caches, process telemetry, and build history to determine whether npm installed it or application code imported it.

Is this proof that the named companies were compromised?

No. Three packages use dependency-confusion-style names, but the advisories do not establish that the apparent target organizations, their accounts, or their private registries were breached.

Is deleting node_modules enough?

No. A lifecycle script or executed module may have accessed secrets, contacted remote systems, or changed files outside the dependency directory. Investigate the host, rotate reachable credentials, clear caches, and rebuild cleanly.

Will npm audit always find malicious packages?

Only after the package and affected version are represented in advisory data available to npm audit. It is useful for known issues but is not a guarantee against newly published or undisclosed malware.