6 Malicious npm Packages: Check Exposure Now

Short answer: OpenSSF and OSV disclosed six malicious npm packages on September 4, 2026: 2nestjs, tailwind-aspect, taskforge-8xv, taskforge-9xv, text-transform-plus, and xcryption. Their documented behavior includes secret theft, reverse-shell execution, and unverified remote-code loaders, so affected systems need more than a dependency update: remove the package, preserve evidence, and investigate the host.

The authoritative records were published between 05:18:47 and 05:21:00 UTC on September 4, 2026. That original disclosure window is less than 72 hours old at the time of writing, and the 2026 year matches the current year; this is a current advisory, not a resurfaced older incident.

Which malicious npm packages and versions are affected?

The advisory set covers six package names and nine published versions. OSV does not list a repaired release for any of them. Do not “upgrade to latest” and assume the problem is solved; remove the dependency unless a trustworthy maintainer later publishes and independently verifies a clean replacement.

2nestjs is a numeric-prefix lookalike for NestJS. Its postinstall path filters environment variables whose names begin with terms such as SECRET, API, TOKEN, or KEY, sends values to a hard-coded TCP endpoint, and invokes Netcat with a shell connection. If that lifecycle script ran, credentials available to the installation process should be treated as potentially exposed.

tailwind-aspect impersonates the naming of Tailwind’s official aspect-ratio plugin. The package fetches JavaScript from a bare IP over cleartext HTTP and executes the downloaded file when the module is imported. An installation that never imported the package may not have triggered this documented path, but it is still evidence that a malicious dependency entered the project.

The two taskforge packages act as remote-code delivery clients. They fetch bytes from an operator-configured origin and pipe them to a detached node - child process without a cryptographic signature or trusted hash. Because the served content can change independently of the npm tarball, responders cannot determine the final payload from the package version alone.

text-transform-plus and xcryption share a postinstall loader that retrieves a ZIP archive from a file-sharing URL, extracts it in a hidden randomized temporary path, and launches a discovered executable or script. The loader avoids CI or production-like environments, hides the child process, and suppresses errors, which makes a successful install an unreliable indicator that nothing happened.

How can you check whether your project is exposed?

Check resolved dependency data, not only the direct dependencies in package.json. A package can arrive transitively, through a workspace, in an older branch, or in a cached CI install.

1. Search every lockfile. From a repository root, run:
   rg -n '"(2nestjs|tailwind-aspect|taskforge-8xv|taskforge-9xv|text-transform-plus|xcryption)"' --glob 'package-lock.json' --glob 'npm-shrinkwrap.json' --glob 'yarn.lock' --glob 'pnpm-lock.yaml'
2. Ask the package manager for the dependency path. For an installed npm tree, run:
   npm ls 2nestjs tailwind-aspect taskforge-8xv taskforge-9xv text-transform-plus xcryption --all
3. Check build and install records. Search CI logs, image build logs, dependency-bot changes, and artifact manifests for the package names and affected versions.
4. Inspect historical revisions. Search active release branches and commits deployed since the package first entered your dependency graph. A clean current branch does not prove an earlier runner or workstation was unaffected.
5. Inventory developer and automation hosts. Identify where npm install, npm ci, Yarn, or pnpm ran and whether the suspicious module was imported or its CLI configured.

You can also use the free InstallSafe package scan for a quick advisory check, then follow the dependency path in the relevant lockfile. For a broader pre-install review process, see the npm package safety checklist.

What should you do if an affected package was installed?

1. Isolate the host or runner. Stop using it for releases and prevent further outbound communication while preserving the evidence your response process requires.
2. Preserve evidence before cleanup. Retain lockfiles, install logs, process history, relevant network telemetry, the package tarball, and a list of credentials available to the process. Avoid running the malicious package again to “test” it.
3. Remove the package and rebuild cleanly. Delete it from direct and transitive dependency paths, regenerate the lockfile deliberately, invalidate relevant caches, and rebuild artifacts on a known-clean system.
4. Rotate reachable secrets. Prioritize npm and GitHub tokens, cloud credentials, deployment keys, signing material, CI secrets, database credentials, and application tokens accessible to the affected account. Revoke old values before issuing replacements where possible.
5. Hunt for follow-on activity. Review child processes, scheduled tasks, startup entries, new files in temporary and application-data directories, unusual DNS or HTTP requests, and authentication activity after the suspected execution time.
6. Check shipped artifacts. Confirm that containers, serverless bundles, desktop builds, and release archives do not retain the dependency or output produced by an untrusted host.

Merely deleting node_modules is not sufficient when install-time or import-time code may already have executed. The safe response boundary is the affected host and every secret it could access, not just the repository directory.

How does a registry firewall help with malicious npm packages?

A registry firewall sits on the dependency download path and evaluates requested package versions before they reach developer machines, CI runners, or coding agents. Once an advisory source such as OSV flags a version, the firewall can deny that exact version consistently across teams instead of relying on every engineer to notice an alert.

That matters for this batch because several payloads execute during postinstall, while another executes when imported. Blocking at the registry boundary prevents the tarball from reaching the step where lifecycle or application code can run. Central logs also show which project requested a blocked version, creating a useful investigation lead.

InstallSafe uses OSV.dev advisory data to block flagged versions and serves byte-for-byte upstream tarballs for allowed packages. It covers local installs, CI, and agent-driven package installation through the configured npm registry endpoint. The npm registry firewall guide explains the architecture and rollout steps.

A registry firewall is not a zero-hour detector. Advisory-backed controls begin protecting after the package version has been identified and published in the feed. Behavioral-analysis tools can sometimes detect suspicious install scripts or network behavior before a public advisory exists, so mature programs combine behavioral inspection, locked dependencies, least-privilege runners, egress controls, and registry enforcement. The malicious npm package response guide maps those layers to common attack paths.

What should teams change after this advisory?

• Require reviewed lockfile changes and pin CI installations with npm ci.
• Run dependency installs in isolated, short-lived environments with minimal secrets.
• Disable lifecycle scripts where the build permits it, while testing the operational impact.
• Restrict outbound network access from build jobs to destinations the job actually needs.
• Continuously scan lockfiles and container inventories against current advisories.
• Enforce blocked package versions through a registry proxy or firewall.

The central lesson is that package installation is code execution. Names that resemble familiar frameworks or utility libraries are not evidence of trust, and a clean-looking exported API does not make lifecycle scripts safe.

Frequently asked questions

Is there a safe version of these six packages?

No safe release is listed in the cited OSV records. Remove the package rather than selecting another published version unless a trustworthy source later confirms a clean replacement.

Does a lockfile match prove the malware executed?

No. It proves the affected version was resolved. Determine whether installation completed, lifecycle scripts were enabled, and import-time or CLI paths ran on each relevant host.

Is deleting node_modules enough?

No. Some packages execute during installation or import and may affect files, processes, credentials, or remote accounts outside node_modules. Rebuild cleanly and follow incident-response procedures.

Should every secret be rotated?

Rotate credentials that the affected process or account could access, prioritizing high-impact tokens and keys. Use logs and host scope to make the response complete rather than indiscriminate.

Will npm audit find malicious packages?

It may report versions represented in the advisory data available to its audit service, but teams should also scan lockfiles directly and enforce policy before installation. No single scanner replaces host investigation after code execution.