TL;DR: Eight zero-dependency npm packages showed dependency confusion behaviour and, in the canonical sample, a postinstall hook that targets AWS Lambda runtime variables and attempts to consume invocation events before the handler runs, according to Xygeni. That shifts the issue from generic supply-chain malware to serverless runtime interception, where package resolution and install scripts become part of the attack surface.
NHIMG editorial — based on content published by Xygeni: the npm dependency confusion cluster with AWS Lambda runtime hijack behavior
Questions worth separating out
Q: What breaks when dependency confusion is allowed in CI/CD pipelines?
A: Build systems can install malicious public packages instead of trusted internal dependencies, which turns normal package installation into an execution path for secret theft.
Q: Why do install scripts make package supply-chain attacks more dangerous?
A: Install scripts run automatically, so they bypass the assumption that code must be imported or called before it can do harm.
Q: How do security teams know if a suspicious package touched a Lambda environment?
A: Look for package install records, layer build logs, and runtime artefacts that show AWS_LAMBDA_RUNTIME_API or calls to the Lambda Runtime API.
Practitioner guidance
- Scope internal package names to private registries Block public registry resolution for internal-looking prefixes, and require explicit namespace ownership before a package can be installed in CI, containers, or serverless build paths.
- Inspect lifecycle scripts before installation Flag preinstall, install, and postinstall hooks as executable code, then quarantine packages that read /proc, environment variables, or runtime endpoints during install.
- Treat Lambda build paths as workload identity boundaries Review any artifact, layer, or image that installs packages in an environment where AWS_LAMBDA_RUNTIME_API may be present, because install-time code can intercept invocation data.
What's in the full analysis
Xygeni's full article covers the operational detail this post intentionally leaves for the source:
- The package-by-package timeline, including publication and unpublish windows, for the eight related npm artefacts.
- The full postinstall code flow that reads the Lambda runtime environment and sends data to the phone-home endpoint.
- The Xygeni Malware Early Warning evidence table with the specific critical and high-severity indicators.
- The recommended npm-side preservation and blocklisting steps for registry operators and response teams.
👉 Read Xygeni's analysis of the npm dependency confusion cluster and Lambda hijack behavior →
Npm dependency confusion and Lambda hijack risk for security teams?
Explore further
Install-time code execution has become a governance problem, not just a packaging problem. When a package can run arbitrary scripts during installation, package resolution controls and runtime controls merge into the same risk surface. This case shows that dependency management cannot be separated from workload identity and secrets governance. Practitioners should treat package scripts as a policy boundary, not a developer convenience.
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.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: Who is accountable when a public package hijacks an internal dependency name?
A: Accountability sits with the teams that own package governance, registry policy, and build pipeline controls, not just the application owner. If namespace ownership, private registry scoping, and script execution policy are weak, the resulting compromise is a platform and supply-chain control failure as much as an AppSec event.
👉 Read our full editorial: Npm dependency confusion can hijack AWS Lambda runtime events