6 Malicious npm Packages Disclosed September 4

Short answer: Six malicious npm packages were newly disclosed by OSV/OpenSSF on September 4, 2026: box-sign-client, box-sign-client-poc, claude-channel-discord, line-through, real-router-telemetry, and tailwind-contact-forms. If any affected version appears in your lockfiles, build logs, caches, or installed dependency trees, remove it and treat any machine that executed it as a potential security incident.

The authoritative records were originally published between 06:33:49 and 06:48:54 UTC on September 4, 2026. That makes this a current disclosure, not a newly indexed copy of an older incident. The year also matches the current year, 2026.

Which malicious npm packages are affected?

The affected names and versions are narrow, but several payloads run automatically during installation or when the module is imported. There are no patched versions in the OSV records. Do not “upgrade” to another release unless a trusted upstream later publishes a verified replacement; remove the package instead.

The primary records are MAL-2026-15920, MAL-2026-15921, MAL-2026-15922, MAL-2026-15923, MAL-2026-15924, and MAL-2026-15925.

What did the packages do?

Dependency-confusion and reconnaissance packages

box-sign-client@1.0.0 and box-sign-client-poc@1.0.0 are public packages positioned against a Box-branded internal namespace. Their install scripts read the local hostname and username, encode those values into a subdomain, and perform a DNS lookup. That lookup exposes the identifiers to a third-party collector before application code runs.

claude-channel-discord@9.9.9 follows a similar dependency-confusion pattern. Its implausibly high version can win version resolution when an internal dependency is referenced without a protected scope or registry rule. It sends the hostname to a Pipedream endpoint during installation and can repeat the beacon when imported.

These packages are labeled or shaped like proof-of-concept probes, but that does not make execution harmless. An unapproved package transmitting machine identifiers is still an incident, especially when the affected host is a CI runner, developer workstation, or build server.

CI metadata and secret-adjacent collection

line-through@1.0.0 runs during preinstall. OSV reports that it requests the installer’s public IP address, reads the hostname, collects CI and GitHub Actions variables such as workflow and run identifiers, and sends the information to a hardcoded webhook. The advisory does not claim that every secret was stolen, so responders should avoid assuming more than the evidence supports. Still, the destination and automatic trigger justify containment.

real-router-telemetry@1.0.1 and 1.0.4 ship a more concerning obfuscated module. It can gather hostname, username, current directory, platform details, memory and CPU information, process listings, Linux release data, and the current project’s .env file before posting the result to a webhook. OSV specifically notes that the examined 1.0.4 package’s install hook points to a stub and is not currently wired to the telemetry module. That distinction matters: presence of the staged payload is confirmed, but automatic execution through that particular hook is not.

Tailwind package impersonation

tailwind-contact-forms@0.5.12 presents itself as though it belongs to the legitimate Tailwind Labs project. The genuine package is @tailwindcss/forms. The malicious lookalike includes copied plugin code plus a large obfuscated section that references host information, environment data, and Ethereum-related network infrastructure. Because the altered file is the package entry point, the payload runs when an application imports it.

This is a reminder that a familiar repository URL in package.json is not proof of package ownership. Confirm the exact scoped name, publisher, release history, and provenance before adding a dependency. Our broader guide explains how to check whether an npm package is safe before installation.

How do I check whether my project is exposed?

1. Search every lockfile. Check package-lock.json, npm-shrinkwrap.json, yarn.lock, and pnpm-lock.yaml across active branches and archived build contexts.
2. Inspect the resolved dependency tree. Run npm ls box-sign-client box-sign-client-poc claude-channel-discord line-through real-router-telemetry tailwind-contact-forms --all. Repeat with the equivalent pnpm or Yarn command when appropriate.
3. Search CI history. Lockfiles show declared resolution, while build logs and dependency caches help establish whether an affected version was actually downloaded or executed.
4. Check developer and runner caches. Inspect npm, pnpm, Yarn, container-layer, and artifact caches. A deleted registry package can remain in a cache or previously built image.
5. Review outbound activity. Look for unexpected DNS requests to canarytokens.com and HTTPS traffic to Pipedream or webhook.site. Match timestamps to package installation and application startup.

rg -n 'box-sign-client|box-sign-client-poc|claude-channel-discord|line-through|real-router-telemetry|tailwind-contact-forms' \
  --glob 'package*.json' --glob 'npm-shrinkwrap.json' \
  --glob 'yarn.lock' --glob 'pnpm-lock.yaml' .

npm ls box-sign-client box-sign-client-poc claude-channel-discord \
  line-through real-router-telemetry tailwind-contact-forms --all

A clean npm ls result is useful but not conclusive. The dependency may have existed in an earlier lockfile, a deleted branch, an ephemeral build, or an image that is still deployed. Check source history and build artifacts as well. For a broader workflow, see our npm malware check and vulnerability scanner guide.

What should I do if an affected version ran?

1. Isolate the host or runner. Stop further builds and prevent the machine from reaching sensitive systems while you preserve relevant logs.
2. Remove the package and rebuild from a known-good state. Delete affected lockfile entries only through a controlled dependency update, clear untrusted caches, and rebuild images and artifacts.
3. Rotate exposed credentials. Prioritize values present in project .env files and CI environments. Rotate from a clean machine, including cloud, registry, source-control, deployment, and application credentials.
4. Review account and infrastructure activity. Look for unexpected workflow runs, package publications, repository changes, cloud API calls, and deployments after the first possible execution time.
5. Block the exact names and versions. Add policy controls so the same packages cannot be reintroduced through a branch, bot, or autonomous coding agent.

Do not rely on uninstalling alone. An install-time hook executes before the package becomes part of the finished application, so removing node_modules does not undo transmitted data. Incident response should be proportional to what each advisory confirms and what your own network and endpoint evidence shows.

How does a registry firewall help?

A registry firewall sits on the dependency download path. Once advisory data identifies a package version as malicious, the firewall can reject that exact artifact before npm, pnpm, Yarn, CI, or an AI coding agent receives it. Central policy also prevents each developer from having to maintain a separate blocklist.

InstallSafe uses OSV.dev advisory data to block flagged versions at the registry boundary and serves byte-for-byte upstream tarballs for allowed packages. That is useful for these six versions now that authoritative records exist. It is not a zero-hour behavioral detector: a newly published malicious package can exist before OSV has a record. Teams that need pre-advisory detection should combine registry controls with behavioral analysis, package-age policies, restricted install scripts, egress controls, and endpoint monitoring.

You can use the free InstallSafe package scan for a quick advisory check, then enforce the same decision at install time for developer machines, CI pipelines, and agents.

Frequently asked questions

Are there safe patched versions?

No patched versions are listed in the six OSV records. Remove the packages. For the Tailwind lookalike, use the legitimate @tailwindcss/forms package only after verifying it is the dependency you intended.

Does --ignore-scripts prevent every payload here?

No. It can suppress lifecycle hooks, but claude-channel-discord and tailwind-contact-forms also execute behavior when imported. It is one defense, not a complete containment strategy.

Should I rotate secrets if the package only collected a hostname?

Base the response on the package and evidence. The Box-named probes are reported to transmit host and user identifiers, while real-router-telemetry contains logic capable of reading .env. If you cannot establish which code executed, choose the safer credential-rotation scope.

Why can an npm audit miss a malicious package?

Audit results depend on the advisory data and package-version mapping available at scan time. A malicious release can be downloadable before a record is published, and some tools focus on vulnerable dependencies rather than malicious behavior.

Is a package labeled “proof of concept” safe to run?

No. A label does not neutralize automatic data transmission. Test only in an isolated environment with controlled networking and no real credentials, and never allow an unapproved probe into routine builds.

Disclosure note: this article is defensive guidance based on the OSV/OpenSSF records available at 10:00 UTC on September 4, 2026. Recheck the primary advisories for updates before making final incident-response decisions.