Which versions of dds-js-idl are malicious?

The following npm versions of dds-js-idl are flagged malicious: 1.0.0, 1.0.1. Treat any of these as compromised.

How do I remediate dds-js-idl if I installed it?

dds-js-idl 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 dds-js-idl — how do I know if it already compromised me?

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

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

Malicious package

dds-js-idlnpm

Malicious code in dds-js-idl (npm) Remove it immediately and rotate any exposed credentials.

MAL-2026-4264

Immediate action

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

npm uninstall dds-js-idl

What this malware does

On npm install, postinstall.js runs whoami via execSync and collects os.hostname(), os.platform(), cwd, and CI/GitHub env vars, then exfiltrates them over HTTPS GET to lg5ys3jebfzwk366pilidbmah1nsbszh.oastify.com/nasa/dds-js-canary/ and additionally performs a DNS lookup of ${whoami}.lg5ys3jebfzwk366pilidbmah1nsbszh.oastify.com as a DNS-channel fallback that defeats egress HTTPS filtering. The package self-describes as a Security research canary — NASA VDP, but it fires on every install without consent and leaks installer identity and repository/CI context to a third-party Interactsh (oastify.com) collector controlled by the canary operator. Regardless of stated research intent, the structural behavior is install-time host fingerprinting and out-of-band exfiltration.

The OpenSSF Package Analysis project identified 'dds-js-idl' @ 1.0.0 (npm) as malicious.

It is considered malicious because:

The package executes one or more commands associated with malicious behavior.

Malicious versions

2 flagged

1.0.01.0.1

Indicators of compromise (SHA-256)

282ab4387de68701d586cdeb6635a576abea042584decbb31640112e9292e83a

4b8ad096ffbd5b819ff05fa2e7240e8b64ab4f0c66bbcd5b3067e062d6bbbf29

9762fd0560dfcdafa569313e27731335cf7544e6101c559dc6a41fda68b94ad8

c864bc6e21a3795faba4de876942dfffa4baed76c926d96d52c83c32d1f49f69

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

Campaign

IN-MAL-2026-004286IN-MAL-2026-004285IN-MAL-2026-004280

References

Credits

Amazon Inspector · finder
OpenSSF: Package Analysis · finder

Detect & block this

O3 blocks dds-js-idl-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