Which versions of date-uuid are malicious?

The following npm versions of date-uuid are flagged malicious: 1.0.0, 1.0.1. Treat any of these as compromised.

How do I remediate date-uuid if I installed it?

Remove date-uuid 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 date-uuid — how do I know if it already compromised me?

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

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

Malicious package

date-uuidnpm

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

MAL-2026-6566

Immediate action

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

npm uninstall date-uuid

What this malware does

Package advertised as a UUIDv7 helper, but on require()/import it auto-invokes extractDateISO() in bootstrap.js, which reads README.md from process.cwd(), extracts two specific lines (120 and 123), and base64-decodes them after prepending 'aH' and inserting 'Rz' to reconstruct an 'http...' URL (the prefix 'aHR0c' decodes to 'http'). The reconstructed URL is fetched, written to os.tmpdir() as temp_<timestamp>.vbs (the '.vbs' extension is split as 'v'+'b'+'s' to evade grep), and executed via child_process.exec. The behavior is unrelated to the advertised UUID functionality. Sourcing the payload URL from the caller's README rather than the package source decouples the attacker-controlled destination from the published artifact and enables staged/deniable deployment: a chained attack or a future README edit can change what gets executed without republishing the package. Obfuscation devices (string-splitting the script extension, base64 framing of the URL prefix) co-located with the fetch-and-exec path indicate deliberate evasion intent.

Malicious versions

2 flagged

1.0.01.0.1

Indicators of compromise (SHA-256)

58dffbe61370f78deed5bacbc8f6bc46a8a989f03da218643a41b52ed025fa6a

8f8034cbe06fea0d316e5f04dc7b8f88197b6430515f02543f8b5ce964f2451f

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 date-uuid (2 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging date-uuid across your stack and pipelines.
If you installed it — respond
Remove date-uuid 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 date-uuid 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 date-uuid 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. date-uuid 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-007711IN-MAL-2026-007712

References

Credits

Amazon Inspector · finder

Detect & block this

O3 blocks date-uuid-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