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.
At a glance
What this is: Xygeni identifies an npm dependency confusion cluster that uses internal-looking package names and a postinstall hook to target AWS Lambda runtime events.
Why it matters: For IAM and platform teams, the risk is that package resolution and install-time scripts can become an access path into serverless execution context, request data, and cloud metadata.
Context
Dependency confusion is a package resolution problem, but its impact depends on where the malicious package executes. In this case, the security issue is not simply that an npm package is suspicious. The concern is that an install script can run inside a build, container, CI, or Lambda-adjacent environment where runtime variables and invocation data are present.
The identity and governance angle is straightforward: serverless and pipeline environments expose machine credentials, runtime metadata, and request context as part of normal operation. When a public package can impersonate an internal dependency name, the trust boundary shifts from code import to package installation and execution. That is why internal naming schemes and lifecycle scripts need explicit governance.
Key questions
Q: What breaks when a dependency confusion package runs inside a Lambda build path?
A: The build path stops being a safe staging area and becomes part of the attack surface. A malicious package can execute during install, inspect runtime context, and interfere with serverless event handling before the legitimate function code even starts. The practical failure is not just code execution, but loss of control over what data the function receives and when it is processed.
Q: Why do Lambda runtime variables increase the impact of a poisoned npm package?
A: Because they expose the runtime endpoint that serves invocation events. If a package can read AWS_LAMBDA_RUNTIME_API during install, it may reach the runtime API directly and consume the next event before the handler processes it. That turns a supply-chain issue into an execution-integrity problem for serverless workloads.
Q: What do security teams get wrong about package install scripts?
A: They treat install scripts as minor convenience features instead of execution points. A malicious preinstall hook can run before application code and before most defenders expect malicious behaviour. In CI and developer environments, that makes package lifecycle scripts a direct control surface.
Q: How should organisations respond when internal package names can be published publicly?
A: They should treat namespace control as an access-control problem. Internal package prefixes need registry pinning, approval controls, and monitoring for public lookalikes, because attackers can exploit naming collisions to get code executed in trusted pipelines. The goal is to make public impersonation ineffective before it reaches a build or deploy stage.
Technical breakdown
How dependency confusion turns package names into execution paths
Dependency confusion happens when a build or deployment system resolves a public package that looks like an internal dependency. The attack does not require the target application to import the package at runtime. If the installer executes lifecycle scripts, attacker-controlled code runs during installation, which is enough to reach the build host, CI runner, container image, or other adjacent environment. In this case, the internal-looking prefix is the clue: it suggests a namespace collision rather than a normal public utility. That matters because the package manager, not the developer, becomes the decision point for whether untrusted code enters the pipeline.
Practical implication: Treat internal-looking package names as a policy problem, not just a code review issue.
Why postinstall scripts are the real attack surface in npm
npm lifecycle scripts such as preinstall, install, and postinstall are executable steps, not metadata. A postinstall hook can run before the application starts, before tests pass, and before a developer notices anything unusual. That gives the package a chance to inspect the environment, read process context, and perform network calls during installation. The malicious value is often hidden in the fact that the install succeeds normally. A package that fails loudly is easier to spot; a package that succeeds while silently reaching out is far more dangerous because it blends into routine build activity.
Practical implication: Review and restrict install-time scripts in every environment that can execute third-party packages.
How AWS Lambda runtime interception works inside a compromised build
AWS Lambda exposes a runtime API through the AWS_LAMBDA_RUNTIME_API environment variable. A malicious install script that finds this value can talk to the Lambda runtime endpoint and request the next invocation event. That event may contain request headers, request IDs, account context, and application payload data before the legitimate handler processes it. The attack is not traditional credential theft alone. It is runtime interception, where the package abuses the Lambda execution model to consume or exfiltrate work that was intended for the function handler. In effect, the install script reaches into the serverless control flow itself.
Practical implication: Assume any package able to read Lambda runtime variables can affect event integrity, not just confidentiality.
Threat narrative
Attacker objective: The attacker wants to intercept Lambda invocation data and harvest runtime context from environments that trust the poisoned package.
- Entry occurs when a public npm package with an internal-looking name is selected during dependency resolution and installed into a build or runtime-adjacent environment.
- Credential and context access occurs when the postinstall script reads /proc environment data and looks for AWS_LAMBDA_RUNTIME_API.
- Impact occurs when the script calls the Lambda runtime invocation endpoint to consume an event and forwards captured data to an attacker-controlled endpoint.
Breaches seen in the wild
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
- PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Install-time execution is now a first-class runtime risk: dependency confusion is no longer just a package selection mistake when the payload can consume serverless invocation events. The trust boundary has moved from import-time behavior to install-time behavior, and that matters wherever build systems, layers, or containers touch privileged cloud context. Teams should treat package installation as an execution phase with its own controls, not as a passive delivery step.
Lambda event integrity depends on more than handler code: the attack works because AWS Lambda exposes a runtime API that sits beside the handler lifecycle. If a malicious package can reach that API during install, it can interfere with the event before application logic ever runs. This is a control gap in serverless governance, where identity, entitlement, and runtime context converge. Practitioners need to govern who can introduce executable dependencies into Lambda build paths.
Internal namespace protection is the named concept this case exposes: internal package-name patterns only remain safe when private registries, scoped resolution, and policy enforcement prevent public impersonation. Without that protection, the namespace itself becomes an attack surface. The practical conclusion is that package naming, registry trust, and lifecycle script control must be managed together.
Serverless supply-chain controls must extend into cloud identity boundaries: a malicious npm package that reaches Lambda runtime variables is not only a software supply-chain issue. It becomes a cloud identity and access governance issue because runtime context, request data, and environment secrets can be exposed through a trusted build path. Organisations should align package controls with cloud execution boundaries, not just with repository policy.
Detection must focus on behavior, not only vulnerability status: there may be no CVE, no long-lived artifact, and no surviving public tarball after unpublish. That means behavioral controls such as install-script inspection, registry policy, and build-time anomaly detection are the meaningful defensive layer. The practitioner takeaway is simple: if the package can execute during install, it can also betray trust during install.
What this signals
Namespace trust has become a security control: internal-looking package names only remain safe when private registry resolution, scoped publishing, and lifecycle-script controls are enforced together. Once public packages can impersonate internal dependencies, the package manager becomes an access path into build systems and serverless environments.
Serverless threat models must include event interception: the distinctive risk here is not generic malware but a package that can consume Lambda invocation data before the handler runs. That means runtime integrity, request handling, and environment exposure now sit inside the same governance problem, especially for teams running CI-to-Lambda delivery pipelines.
Install-time behaviour deserves continuous scrutiny: a malicious package does not need persistence to cause damage if it can act during one install window. Build policy, dependency pinning, and runtime-variable monitoring should be designed to catch short-lived execution patterns, not just known-bad package versions.
For practitioners
- Restrict install-time scripts in trusted build paths Block or review preinstall, install, and postinstall execution for packages that can reach CI, container build, or Lambda layer environments.
- Force private registry resolution for internal namespaces Pin internal package prefixes to private registries and reject public packages that mimic internal naming schemes such as numeric prefixes or version-like suffixes.
- Monitor Lambda builds for runtime-variable access Alert when third-party packages read AWS_LAMBDA_RUNTIME_API or attempt to call the Lambda Runtime API during package installation.
- Preserve and inspect unpublished tarballs Retain unpublished package artifacts in internal storage so you can recover phone-home destinations, compare sibling payloads, and support incident response.
- Rotate secrets exposed to the install environment Treat Lambda layers, deployment images, and CI runners as potential exposure points and rotate AWS keys, CI tokens, and deployment credentials after suspicious installs.
Key takeaways
- Dependency confusion becomes more serious when the payload can run during install and interact with a cloud runtime rather than only loading into an application.
- The key technical risk in this case is Lambda event interception, not just secret theft or suspicious package publication.
- Practitioners should govern package namespaces, install scripts, and serverless build paths as one control surface because that is where the trust break occurs.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | A public package impersonating an internal dependency is a third-party NHI supply chain problem. |
| NHI-02 — Secret Leakage | The install script reads process context and may expose runtime data and secrets. | |
| Recommendation — Inventory third-party package sources and block untrusted public packages from internal dependency paths. Scan install paths for secret-exposing behavior and revoke credentials if package code touches runtime context. | ||
| MITRE ATT&CK | TA0002;TA0010 — Execution; Exfiltration | The package executes during install and sends captured data to an external endpoint. |
| Recommendation — Map suspicious lifecycle hooks to execution and exfiltration techniques in your detection pipeline. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Package resolution into trusted environments depends on enforced access and authorization boundaries. |
| Recommendation — Apply entitlement controls so only approved packages can execute in privileged build and runtime environments. | ||
| CIS Controls v8 | CIS-5 — Account Management | The publisher account and package publishing lifecycle are part of the abuse pattern. |
| Recommendation — Review publisher and registry account governance to remove low-trust accounts from release paths. | ||
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.
- Preinstall Hook: A preinstall hook is package code that runs before an application installs or starts. In supply-chain attacks, it becomes a hidden execution point that can steal secrets, alter environments, or drop further payloads before normal controls see the package's behaviour.
- Serverless Runtime API: The serverless runtime API is the interface a function runtime uses to receive the next invocation event and return results. In AWS Lambda, access to this API can expose request data and execution context, so abuse of the runtime endpoint can affect both confidentiality and integrity.
- Package Namespace Governance: Package namespace governance is the control practice that keeps internal dependency names from being impersonated by public packages. It combines registry scoping, publishing policy, and resolution rules so that package names cannot be used as an attack path into trusted build and runtime environments.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for practitioners who need to connect identity governance to real operational controls across modern security programmes.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org