Notifications
Clear all
Topic starter
18/08/2026 2:40 pm
TL;DR: Twenty npm packages published in late July and early August 2026 hid malware that executed on import, not during install, so --ignore-scripts did not block it; Xygeni’s analysis shows staged payload retrieval, endpoint-security enumeration, AMSI and ETW patching, and in-memory execution.
NHIMG editorial — based on content published by Xygeni: import-time npm malware and staged loader behaviour in twenty packages
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams handle npm packages that run code during install?
A: Security teams should treat install-time scripts as executable code and restrict them by policy.
Q: Why do import-time payloads increase supply chain risk for NHI secrets?
A: Because they execute inside the same environments that usually hold API keys, tokens, certificates, and automation accounts.
Q: What breaks when teams rely only on --ignore-scripts?
A: They miss code that runs outside npm lifecycle hooks.
Practitioner guidance
- Inspect module entry points for hidden execution Review package index files, bootstraps, and require chains for code that executes on import, not only during npm lifecycle scripts.
- Harden CI and developer environments against secrets exposure Reduce the blast radius of imported code by limiting which service credentials, API keys, and tokens are available on build runners and developer workstations.
- Detect temporary-file launch and persistence artefacts Look for executables written to temporary directories, launched detached, and followed by Run key, scheduled task, or LaunchAgent creation.
What's in the full report
Xygeni's full analysis covers the operational detail this post intentionally leaves for the source:
- Package-by-package indicators that distinguish the malicious names from the benign lookalikes
- Binary-level inspection notes on the loader, persistence mechanisms, and anti-analysis behaviour
- The full timeline of publication, unpublication, and republishing across the affected npm names
- Additional infrastructure details around the delivery hosts and DNS fallback path
👉 Read Xygeni's analysis of import-time npm malware and staged loader behaviour →
Import-time npm malware: are your build controls catching it?
Explore further
18/08/2026 3:25 pm
Import-time execution is the new supply chain blind spot: this campaign shows that install-time hardening is necessary but not sufficient. Packages can be weaponised in the module entry point, which means code review must extend to package initialisation paths and dependency provenance. For IAM and NHI teams, that is the point where trusted build activity becomes credential exposure risk.
A question worth separating out:
Q: Who is accountable when a trusted dependency steals build-time secrets?
A: Accountability is shared across application owners, platform teams, and identity governance. Application teams own dependency review, platform teams own runner hardening, and identity teams own the scope and lifetime of the credentials exposed to those environments. If the same secrets are available everywhere, ownership has not been translated into control.
👉 Read our full editorial: Import-time npm malware shows why scripts-only defences fail
