Topic starter
20/08/2026 5:33 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Xygeni: “AWS Lambda npm Dependency Confusion Attack: The 24712-pl Campaign”.
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.
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.
Q: What do security teams get wrong about package install scripts?
A: They treat install scripts as minor convenience features instead of execution points.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:19 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Npm dependency confusion can hijack AWS Lambda runtime events