Which versions of uncaxss are malicious?

The following npm versions of uncaxss are flagged malicious: 1.3.4, 1.3.5. Treat any of these as compromised.

How do I remediate uncaxss if I installed it?

Remove uncaxss from your project and lockfile, then assume any secrets accessible to the build or runtime were exposed: rotate API keys, tokens, and credentials, and audit for unexpected outbound activity or persistence.

I already installed uncaxss — how do I know if it already compromised me?

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

Yes — uncaxss is associated with the IN-MAL-2026-009713, IN-MAL-2026-009712 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 uncaxss 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 uncaxss (2 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging uncaxss across your stack and pipelines.

Malicious package

uncaxssnpm

uncaxss is a confirmed malicious npm package (MAL-2026-10176) that executes malicious code on install (malicious versions 1.3.4, 1.3.5). Do not install it — remove it immediately and rotate any exposed credentials.

Malicious code in uncaxss (npm)

MAL-2026-10176

Immediate action

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

npm uninstall uncaxss

What this malware does

Package ships an obfuscated dist/index.js that is invoked from the postinstall lifecycle hook (node dist/index.js). At install time, the script performs an HTTPS GET to https://onch.cc/test1.txt (and https://onch.cc/test2.txt), base64-decodes the response body, and executes it via new Function('require', decoded)(), granting the fetched code full Node.js capabilities (including require) on the installer's machine. The dropper is gated by process.env.P == 1, allowing the attacker to keep the payload dormant on incidental installers and detonate selectively (e.g., on CI runners where P is set). The fetching logic is obfuscated using javascript-obfuscator (hex identifiers, rotating string array, decoder wrapper), and the package's own build script ("obfuscate": "javascript-obfuscator./dist/index.js...") confirms obfuscation is applied deliberately before publish. The remote host onch.cc is unrelated to any documented package purpose (the package has no README), and the fetched content is opaque, mutable, and unpinned. This is a classic install-time RCE dropper with attacker-controlled remote code execution on npm install.

Malicious versions

2 flagged

1.3.41.3.5

Indicators of compromise (SHA-256)

aa3a99decf218ff512c0594cf9546d295c36215b1b573d64ba2d32c1ead49d68

acda9720ae54881219c0fbcee73795be85877d292aa62662f7cb6b92e775f608

Detection & response playbook

Malicious package

Find it
Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for uncaxss (2 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging uncaxss across your stack and pipelines.
If you installed it — respond
Remove uncaxss from your project and lockfile, then assume any secrets accessible to the build or runtime were exposed: rotate API keys, tokens, and credentials, and audit for unexpected outbound activity or persistence.
Did it already run?
If uncaxss 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 uncaxss 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. uncaxss on npm has been identified as a malicious package (versions 1.3.4, 1.3.5 flagged). It should be removed immediately — do not install or keep it in your dependency tree.

Campaign

IN-MAL-2026-009713IN-MAL-2026-009712

References

Credits

Amazon Inspector · finder

Detect & block this

O3 blocks uncaxss-class packages before install and in CI — and if it already ran, its runtime egress monitoring catches the malicious outbound activity and severs the channel.

Malware detection Runtime egress monitoring

Explore

All malware advisories How O3 detects malware Vulnerability database