Npm dependency confusion can hijack AWS Lambda runtime events

At a glance

What this is: This is an analysis of an npm dependency confusion cluster that used install-time code to target AWS Lambda runtime execution and exfiltrate invocation data.

Why it matters: It matters because build, CI/CD, and serverless teams must treat package name resolution and lifecycle scripts as executable attack surface, not just dependency metadata.

👉 Read Xygeni's analysis of the npm dependency confusion cluster and Lambda hijack behavior

Context

Dependency confusion is a supply-chain attack in which a public package is published to match an internal dependency name or naming pattern, then executed when build tooling resolves it ahead of the intended private package. In this case, the naming pattern strongly suggests an internal namespace rather than a normal public library, and the install hook makes the package active before application code ever runs.

The governance gap is not just malicious code in a registry. It is the combination of weak namespace protection, install-time script execution, and cloud runtime exposure, which is especially dangerous where AWS Lambda execution context is available. For identity and access teams, this is a Non-Human Identity problem as much as an AppSec problem because the attacker is targeting runtime secrets, environment variables, and workload-level access paths.

The publisher’s self-unpublish behaviour adds another operational risk: visibility drops after the fact, but cached artefacts, lockfiles, and build logs can still preserve exposure evidence. That pattern is typical of modern supply-chain abuse, not a one-off curiosity.

Key questions

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. The failure is not only malware execution. It is the loss of control over where code comes from and what identity-bearing material the runner exposes during install.

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. In practice, that gives attackers an execution path inside build systems, containers, and serverless layers, where they can read environment variables, contact runtime APIs, or stage follow-on exfiltration.

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. Also inspect whether invocation events were missing, truncated, or diverted during the installation window, because that is the strongest sign of runtime interception.

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.

Technical breakdown

How dependency confusion turns package names into code execution

Dependency confusion succeeds when package managers or build systems resolve a public package that resembles an internal one. The attacker does not need to compromise the target repository directly. They only need a name that matches the resolver’s expectations, then malicious lifecycle scripts such as preinstall, install, or postinstall can execute during dependency installation. That makes package metadata, namespace patterns, and lockfile behaviour part of the trust boundary, especially in CI/CD and container builds where automation runs without interactive review.

Practical implication: lock internal namespace prefixes to private registries and block public resolution for names that should never exist on npm.

Why postinstall hooks are a high-risk execution path

npm lifecycle hooks are executed as part of package installation, before application import or runtime validation. A postinstall script can therefore run even when the package is never used by the application code. In this case, the use of || true is a common stealth pattern because it prevents install failure from exposing the payload. That is why package review must include script inspection, not just vulnerability scoring or semantic version checks.

Practical implication: enforce policy controls that inspect and, where necessary, block install scripts in pipelines and build images.

How AWS Lambda runtime hijack works at install time

AWS Lambda exposes AWS_LAMBDA_RUNTIME_API to the execution environment so custom runtimes can fetch the next invocation from the Runtime API. The malicious package looks for that variable, then calls the /2018-06-01/runtime/invocation/next path to consume the event payload before the legitimate handler processes it. This is a workload identity abuse pattern, not just data theft. If the script runs in a Lambda build layer, deployment image, or init wrapper, it may capture headers, request bodies, account context, and invocation metadata that belong to the function’s runtime identity.

Practical implication: treat Lambda build and init environments as part of the workload identity perimeter and audit any package that touches runtime endpoints.

Threat narrative

Attacker objective: The attacker aims to intercept Lambda invocation data and associated runtime context before the legitimate function handler can process it.

1. Entry occurs when a public npm package is published under an internal-looking dependency name and is selected by dependency resolution.
2. Escalation occurs when the package’s postinstall hook runs during npm install and reads the parent process environment for AWS runtime variables.
3. Impact occurs when the script calls the Lambda Runtime API to consume the next invocation event and exfiltrate runtime data to an attacker-controlled endpoint.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Nx Package Attack — 2,300+ Credentials Leaked — Malicious attack on Nx build platform leaks 2,300+ credentials via compromised open-source package.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Lambda runtime hijack is a workload identity abuse pattern. The malicious logic does not rely on traditional malware persistence or broad system compromise. It targets the execution identity of a serverless function, then consumes the event stream that identity was meant to process. That is a reminder that NHI governance must include ephemeral compute contexts, not only long-lived service accounts and keys.

Namespace trust is the named concept here: internal-looking package prefixes create a false signal of legitimacy. Once teams allow public registries to resolve names that look internal, dependency confusion becomes a naming and governance failure. The practitioner response is to enforce namespace ownership, registry scoping, and install-script policy together, because each control alone leaves a gap.

Secrets exposure and invocation interception amplify one another. Even if the Lambda hijack path fails, reading /proc and runtime environment variables can still leak credentials, tokens, and deployment context. That means package execution inside build and runtime-adjacent environments should be governed as secret-handling activity, not merely software installation. Security teams should align this with NIST SP 800-53 IA and AC controls and OWASP NHI guidance.

Self-unpublish behaviour should be treated as an investigation trigger, not a clean bill of health. Removing a package from the registry does not remove the attack from caches, build artefacts, or lockfiles. This is where supply-chain governance and incident response intersect, because the evidence of compromise may survive only in local artefacts. Teams should preserve those artefacts before the visibility window closes.

From our research:

• 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.
• From our research: Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.

What this signals

Namespace control is now a supply-chain security requirement. Teams that still allow public resolution for internal-looking package names are accepting a dependency confusion path that can reach build systems and serverless execution. The practical response is to pair registry scoping with install-script policy, then validate it against the MITRE ATT&CK Enterprise Matrix where credential access and exfiltration behaviours begin.

Secrets exposure and workload identity abuse are converging in the same attack path. A package that can read runtime variables and invoke a platform API is no longer just a software integrity issue. It becomes a control issue for NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where access control, authenticator management, and auditability are expected to constrain automated execution.

Runtime artefact preservation is the named concept practitioners should adopt next. When suspicious packages are unpublished, the evidence often survives only in caches, layers, and logs. Security teams should formalise artefact preservation as part of incident response so package cleanup does not erase the forensic trail.

For practitioners

• 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.
• Preserve artefacts before registry cleanup completes Retain lockfiles, package caches, build logs, and container layers when a suspicious package is unpublished, because the registry copy may disappear before forensic detail is recovered.
• Rotate secrets exposed to build and init environments Assume that any environment with a malicious install script may have leaked AWS keys, CI tokens, deployment credentials, or database URLs, and rotate them from the affected scope outward.

Key takeaways

• Dependency confusion becomes materially worse when the package’s install script can execute before the application ever imports the dependency.
• The Lambda runtime hijack pattern shows how a supply-chain event can cross into workload identity and invocation interception.
• Private registry scoping, script inspection, and artefact preservation are the controls that most directly reduce this attack path.

Key terms

• Dependency Confusion: A supply chain attack in which a build system resolves a malicious public package instead of an intended internal one because of naming, versioning, or registry precedence. The risk is not only code substitution but automatic execution inside trusted pipelines that already contain valuable credentials.
• Postinstall Hook: An npm lifecycle script that runs automatically after a package is installed. Because it executes without an explicit application call, it can be used as a covert execution path inside CI/CD, containers, and other automated build environments.
• Runtime API Monitoring: Runtime API monitoring inspects API traffic and behaviour while the service is live, rather than only during scheduled scans. It looks for abuse patterns, abnormal request sequences, and misused credentials, making it especially useful where machine-to-machine access changes faster than review cycles.
• Workload Identity: The identity assigned to a software workload — such as a containerised application, serverless function, or microservice — enabling it to authenticate to other services without storing static credentials.

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.

👉 Xygeni's full post covers the package timeline, payload flow, and registry response steps

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and agentic AI identity. It helps security practitioners connect identity controls to the wider build, runtime, and access decisions that shape risk.