Which versions of @nstrlabs/auth are malicious?

The following npm versions of @nstrlabs/auth are flagged malicious: 99.0.0, 99.0.1. Treat any of these as compromised.

How do I remediate @nstrlabs/auth if I installed it?

@nstrlabs/auth is built to steal secrets, so assume every credential the build or runtime could read is compromised. Remove it from your project and lockfile, then rotate ALL exposed secrets — npm/registry tokens, cloud keys, CI/CD secrets, SSH keys, and any .env values — from a known-clean machine. Audit logs for unauthorized use of those credentials.

I already installed @nstrlabs/auth — how do I know if it already compromised me?

If @nstrlabs/auth was ever installed, its post-install/runtime payload may have already executed. O3's L7 egress monitoring and runtime eBPF sensors detect the credential exfiltration or command-and-control callback after install and block the malicious outbound channel, so you catch and contain the actual compromise — not just the presence of the package.

Is @nstrlabs/auth part of a known attack campaign?

Yes — @nstrlabs/auth is associated with the IN-MAL-2026-005084, IN-MAL-2026-005085, IN-MAL-2026-005140, IN-MAL-2026-005141 campaign. Packages in the same campaign often share infrastructure and payloads, so check whether any related packages are also in your dependency tree.

How do I find @nstrlabs/auth across my projects, lockfiles, and CI pipelines?

Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for @nstrlabs/auth (2 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging @nstrlabs/auth across your stack and pipelines.

Malicious package

@nstrlabs/authnpm

Malicious code in @nstrlabs/auth (npm) Remove it immediately and rotate any exposed credentials.

MAL-2026-5419

Immediate action

Remove the package, then rotate any secrets the build/runtime could reach.

npm uninstall @nstrlabs/auth

What this malware does

On npm install, the package's preinstall hook (node index.js || true, declared in package.json) automatically collects host identifiers — os.hostname(), os.userInfo().username, __dirname, and process.cwd() — and exfiltrates them through two channels: (1) a DNS lookup to a hex-encoded subdomain of d8jbmnsqcfu78dfs8vdg34ohqhirb4pbg.oast.live (an out-of-band interaction canary), and (2) an HTTP POST of the JSON payload to the bare IP 172.201.213.59 on port 9090 at path /c. The package ships no other functionality; the entire codebase is a beacon. Combined with the implausible version 99.0.0, the @nstrlabs scope, and the self-described 'security research' purpose, this has the canonical shape of a dependency-confusion attack against a private @nstrlabs/auth namespace, where any organization that mistakenly resolves the public registry copy will leak internal hostnames and developer identities to the attacker.

Malicious versions

2 flagged

99.0.099.0.1

Indicators of compromise (SHA-256)

f9efcc731c346683d950fd8237f2ca892a7971d0cc340a48efcb60ba02abe851

fe577c55bca36113c93b1486725ad4f853775354bd6a7c6e0eb6c300652e2ae4

608be3457e7c809e60c1b76b9406489652f0ef708bfb97db2b6e0bb92b6836c2

6af43df85e84a095699136acc4e3a92111b93764db3d276288e842f3bb17e575

Detection & response playbook

Credential / info stealer

Find it
Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for @nstrlabs/auth (2 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging @nstrlabs/auth across your stack and pipelines.
If you installed it — respond
@nstrlabs/auth is built to steal secrets, so assume every credential the build or runtime could read is compromised. Remove it from your project and lockfile, then rotate ALL exposed secrets — npm/registry tokens, cloud keys, CI/CD secrets, SSH keys, and any .env values — from a known-clean machine. Audit logs for unauthorized use of those credentials.
Did it already run?
If @nstrlabs/auth was ever installed, its post-install/runtime payload may have already executed. O3's L7 egress monitoring and runtime eBPF sensors detect the credential exfiltration or command-and-control callback after install and block the malicious outbound channel, so you catch and contain the actual compromise — not just the presence of the package.
How O3 protects you
O3 blocks @nstrlabs/auth before install through its supply-chain scanner, and if it has already run, detects and severs the exfiltration or C2 callback at runtime through L7 egress monitoring and eBPF.

Frequently asked questions

No. @nstrlabs/auth on npm has been identified as a malicious package (versions 99.0.0, 99.0.1 flagged). It should be removed immediately — do not install or keep it in your dependency tree.

Campaign

IN-MAL-2026-005084IN-MAL-2026-005085IN-MAL-2026-005140IN-MAL-2026-005141

References

Credits

Amazon Inspector · finder

Detect & block this

O3 blocks @nstrlabs/auth-class packages before install and in CI — and if it already ran, its runtime egress monitoring catches the credential exfiltration and severs the channel.

Malware detection Runtime egress monitoring