TL;DR: Six npm packages published over a 24-hour window used preinstall and postinstall hooks to fingerprint hosts, probe cloud metadata, and on Windows escalate to SYSTEM while opening a remote command channel, according to Xygeni. The pattern matters because build runners often carry privileged cloud identities, so dependency installs can become a credential-exposure event, not just a software supply-chain issue.
NHIMG editorial — based on content published by Xygeni: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
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: What breaks when malicious npm packages execute during CI/CD installs?
A: The main failure is that package installation becomes code execution inside a trusted build context.
Q: Why do package installs create NHI risk in cloud build environments?
A: Because the runner identity is often a workload identity with access to metadata services, tokens, and deployment resources.
Q: How do security teams know if dependency installs are operating outside their intended boundary?
A: Look for evidence of network egress during install, access to metadata endpoints, unexpected privilege changes, and scripts that execute before the package is fully trusted.
Practitioner guidance
- Block install scripts in CI by default Use npm install --ignore-scripts or an equivalent control in build pipelines that do not explicitly require lifecycle hooks.
- Isolate build runners from metadata services Prevent dependency-install processes from reaching cloud instance-metadata endpoints such as 169.254.170.2 and 169.254.169.254.
- Rotate any reachable workload credentials If a runner installed one of the affected packages, treat its cloud role tokens, API keys, and other secrets as exposed.
What's in the full analysis
Xygeni's full research post covers the operational detail this post intentionally leaves for the source:
- Exact package names, version ranges, and the observed install-time behaviour across Linux and Windows hosts
- Indicator list for the collector host, Cloudflare tunnel, and registry artefacts that defenders can use for hunting
- Code-level breakdown of the preinstall and postinstall scripts, including the platform dispatcher and beacon logic
- Timeline and publication pattern for the six-package cluster, including the repeated republishes used to keep fresh versions available
👉 Read Xygeni's analysis of the npm install-hook campaign and credential theft →
Install-time npm payloads: what CI and IAM teams need to know?
Explore further
Install-time execution is an identity event, not just a packaging event. This campaign succeeds because npm install runs code under a real workload identity, often inside CI where that identity can see cloud metadata, registries, and secrets. That collapses the usual boundary between software consumption and privileged execution. For identity teams, the lesson is that package managers are access-bearing runtimes and should be governed accordingly.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases.
A question worth separating out:
Q: Who is accountable when a build process loads malicious code and exposes credentials?
A: Accountability usually spans engineering, platform, and security teams because the failure sits at the intersection of dependency governance, secret placement, and host hardening. NIST-style access and audit controls apply to the systems that allowed the process to run with excessive trust.
👉 Read our full editorial: npm install hooks turned into cloud credential theft and remote control