Which versions of sb-original are malicious?

The following npm versions of sb-original are flagged malicious: 9999.99.99. Treat any of these as compromised.

How do I remediate sb-original if I installed it?

sb-original 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 sb-original — how do I know if it already compromised me?

If sb-original 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 sb-original part of a known attack campaign?

Yes — sb-original is associated with the IN-MAL-2026-005257, IN-MAL-2026-005256, GHSA-wv26-jcfp-4phh 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 sb-original 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 sb-original (version 9999.99.99). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging sb-original across your stack and pipelines.

Malicious package

sb-originalnpm

Malicious code in sb-original (npm) Remove it immediately and rotate any exposed credentials.

MAL-2026-5490

Immediate action

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

npm uninstall sb-original

What this malware does

[email protected] is an unscoped package whose version is set to 9999.99.99 to win semver resolution against any internal package of the same name. index.js transparently re-exports the real sb-original module so consumers see normal functionality, while a postinstall script silently fingerprints the installing environment. On npm install, postinstall.js POSTs JSON containing the consuming package name/version, Node version, OS, detected CI provider, and GitHub repository/owner/workflow identifiers to https://ddactic-lab.online/sc/beacon (postinstall.js:32). It also performs a DNS-based fallback that encodes the same fields as a subdomain of b.ddactic-lab.online (postinstall.js:46 dns.lookup(${sl}.${ci}.${h}.b.ddactic-lab.online,...)), which is designed to bypass HTTP egress controls. The combination of an extreme version floor, a transparent proxy main, and unconditional install-time exfiltration of GitHub repo identifiers to an attacker-controlled domain is the canonical dependency-confusion attack shape.

Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

Malicious versions

1 flagged

9999.99.99

Indicators of compromise (SHA-256)

5419fc906c3b5ca1817006530c8ec07e70675fa10fd9c2be97bda76fb56d7d8d

c0e07a765f6ef2042da47b1c017ecc5f6f1f99167da76e04c4b2c4ea6ecfcb83

91923b6b76ff0debad26c6bac2dea8e0634346410ac928f93c02605f21851d27

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 sb-original (version 9999.99.99). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging sb-original across your stack and pipelines.
If you installed it — respond
sb-original 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 sb-original 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 sb-original 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. sb-original on npm has been identified as a malicious package (version 9999.99.99 flagged). It should be removed immediately — do not install or keep it in your dependency tree.

Campaign

IN-MAL-2026-005257IN-MAL-2026-005256GHSA-wv26-jcfp-4phh

References

Credits

Amazon Inspector · finder

Detect & block this

O3 blocks sb-original-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