Dependency confusion in npm: how install-time beacons expose builds

At a glance

What this is: A six-day npm campaign used internal-looking package names, high versions, and preinstall hooks to execute beaconing code during installation.

Why it matters: This matters to IAM and NHI practitioners because package install paths can expose privileged build environments, secrets, and service access even when no human login is compromised.

👉 Read Xygeni’s analysis of the npm dependency-confusion cluster and install-time beaconing

Context

Dependency confusion becomes dangerous when public packages imitate internal namespaces closely enough to win package resolution in a misconfigured build. In this case, the security problem is not just malicious code, but the fact that install-time execution can happen before an application ever runs, turning package management into an access path into developer and CI environments.

The identity angle is indirect but real: build systems, runners, and automation accounts often hold secrets, tokens, and internal network reach that should be treated as non-human identity surfaces. When an npm package can execute at install time, it can observe those environments, validate execution, and potentially reach into the same trust fabric that NHI governance is meant to control.

Key questions

Q: What breaks when remote dynamic dependencies are not controlled in npm builds?

A: Build security breaks because the installer becomes the execution engine. A package can look harmless in the registry while fetching malicious code from an external URL during install, which bypasses many scanners and moves risk into the developer workstation or CI runner. The missing control is policy over what the installer may fetch and execute.

Q: Why do build systems make supply-chain attacks worse?

A: Build systems amplify attacker reach because they routinely hold credentials, sign artefacts, and push code across trusted repositories. Once a malicious package lands in that environment, it can spread through ordinary build steps and inherited permissions. The problem is not just initial infection, but the reuse of trusted automation to propagate it.

Q: What do security teams get wrong about preinstall hooks?

A: They often treat preinstall scripts as packaging detail instead of code execution. In reality, those hooks run before dependency installation completes, so they can act as an earliest possible foothold. Any package with an internal-looking name, no real functionality, and a lifecycle script deserves heightened scrutiny before it is allowed into production pipelines.

Q: How should organisations respond when a suspicious npm package appears in lockfiles?

A: Treat it as an execution event, not just a dependency issue. Preserve lockfiles, caches, build logs, and egress data, then check whether the package ran on a workstation, build agent, or container image. If secrets or cloud tokens were present, rotate the exposed credentials and review registry pinning and script policies immediately.

Technical breakdown

How dependency confusion works in package resolution

Dependency confusion happens when a package manager prefers a public package over the intended private one because the public entry has a matching or higher version. Attackers exploit internal-looking names, namespace patterns, and inflated semver values to influence resolution. The danger rises when build systems are not pinned to private registries or scoped packages. In this cluster, the shift from normal versions to 99.x.x versions is a strong signal that the publisher was trying to outrank internal packages rather than deliver software.

Practical implication: enforce private registry pinning and scoped package controls so public packages cannot satisfy internal dependencies.

Why preinstall hooks are an install-time foothold

npm lifecycle scripts such as preinstall run before dependency installation completes, which means untrusted code can execute without the application importing the package. That gives an attacker an early foothold inside a workstation, container build, or CI runner. Tiny zero-dependency packages are especially suspicious when they exist only to run a lifecycle script. This is a supply chain control problem, not a malware sophistication problem.

Practical implication: restrict or review preinstall execution, especially for small packages that claim internal namespace names.

Why host fingerprinting and beaconing matter in NHI governance

Host fingerprinting tells an attacker whether the package actually executed inside a real target environment, while outbound beaconing confirms reachability and helps map the execution context. In this article, the payload fetched public IP data and posted telemetry to Telegram, which is enough to validate exploitability. For identity teams, the relevance is that CI runners and developer machines often host credentials, tokens, and service access that behave like NHI assets even when they are not formally managed that way.

Practical implication: treat build runners and developer endpoints as credential-bearing systems and monitor their egress like privileged infrastructure.

Threat narrative

Attacker objective: The attacker’s objective was to prove package execution inside a real target environment and use that foothold to identify exposed build or workstation context for later abuse.

1. Entry occurred through public npm resolution of internal-looking package names with inflated version numbers designed to outrank private dependencies.
2. Credential access was not the main payload, but install-time execution on a build host or workstation created a path to observe environment data and validate sensitive runtime context.
3. Impact was achieved when the package posted host fingerprint data to Telegram, confirming code execution inside a real environment and exposing the package resolution weakness.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Coupang Signing Key Breach — Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.

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

NHI Mgmt Group analysis

Dependency confusion is now an identity-adjacent control issue, not just a packaging mistake. Public package resolution can become a path into environments that hold tokens, secrets, and service credentials. When package managers prefer the wrong artifact, the build system itself becomes the trust boundary. Practitioners should treat package naming, registry scoping, and lifecycle-script execution as part of access governance, not just DevSecOps hygiene.

Install-time execution turns ordinary build infrastructure into a non-human identity exposure point. CI runners, developer workstations, and container builders often authenticate to source control, artifact stores, and cloud services. That means a seemingly simple package install can sit on the same trust plane as workload identities. The governance gap is not only malicious code, but unmanaged privilege concentration inside automated systems that many organisations still do not inventory cleanly.

High-version namespace mimicry is a named control gap: version-skew hijacking. The campaign’s move toward 99.x.x releases shows how attackers tune public package metadata to beat private registry expectations. That is a governance failure in dependency policy, not a random abuse pattern. Organisations need package-resolution rules that assume adversarial versioning and namespace imitation will continue.

Telegram beaconing is operational proof, not just exfiltration noise. The payload did not need a full backdoor to matter. A successful outbound message confirms code execution, tells the attacker the target exists, and can reveal whether the host is a workstation, build agent, or container. For practitioners, that means detection should focus on install-time egress from package scripts, not only on post-compromise persistence.

Build-system trust now overlaps with software supply chain and identity lifecycle governance. The same governance discipline used for secrets rotation and service account review should apply to package publishing rights, registry trust, and script execution permissions. If a low-reputation public account can masquerade as an internal dependency, the organisation has a control gap in how it grants software trust. Practitioners should treat dependency resolution as a lifecycle control surface.

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.
• For a broader breach lens: The 52 NHI breaches Report shows how trust in execution paths turns into identity exposure when credentials are reachable by automation.

What this signals

Version-skew hijacking: package resolution policies now need to assume adversarial naming and inflated versions will be used to target internal build paths. Teams that only police malware signatures will miss the real weakness, which is trust in dependency metadata and install-time execution. The control response is to harden registry policy, script execution, and build egress together, not separately.

The broader signal is that build infrastructure increasingly behaves like a privileged identity tier. If a package install can observe environment context, then the runner or workstation is not just a compute asset, it is a credential-bearing system that needs lifecycle oversight. That is the same governance logic applied to service accounts and workload identities, and it should extend to CI access paths.

Dependency confusion is also a reminder that software supply chain controls and identity governance are converging. Public package names, registry trust, and lifecycle hooks are now part of the same risk chain as tokens, secrets, and privileged automation. Practitioners should map those controls against frameworks such as MITRE ATT&CK Enterprise Matrix and the NIST SP 800-53 Rev 5 Security and Privacy Controls.

For practitioners

• Pin package resolution to trusted registries Force private packages to resolve from approved registries only, and block public fallback for internal namespaces. Enforce scoped package patterns so names that resemble internal modules cannot be satisfied by public npm releases.
• Block install-time scripts by default Disallow or heavily review preinstall, install, and postinstall hooks in packages that are small, zero-dependency, or namespace-like. Require exception handling for any package that needs lifecycle execution in build pipelines.
• Monitor egress from build environments Alert on outbound requests to unexpected domains such as Telegram Bot API endpoints or public IP lookup services during dependency installation. Treat install-time network activity as suspicious unless it is explicitly required and approved.
• Preserve build artefacts and lockfiles for forensics Keep npm cache, lockfiles, build logs, and package manager output from the exposure window so you can reconstruct resolution decisions after a package is unpublished. This is especially important when public registry records disappear or versions are stripped.

Key takeaways

• This campaign shows how a package manager can become an execution path into privileged development and build environments.
• The strongest indicators were internal-looking names, inflated versions, install-time hooks, and outbound Telegram telemetry.
• The most effective defence is to combine registry pinning, script controls, and egress monitoring with a forensics-ready response process.

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.
• Package Resolution: Package resolution is the process a package manager uses to decide which artifact satisfies a dependency request. It becomes a security control when registry trust, version precedence, and scope rules determine whether internal or public code is allowed into the build.
• Build Environment Egress: Build environment egress is outbound network traffic generated by CI runners, build agents, or developer tooling during software assembly. Monitoring it matters because install-time scripts often reveal compromise through unexpected calls to external services, lookup endpoints, or messaging APIs.

What's in the full analysis

Xygeni's full post covers the operational detail this post intentionally leaves for the source:

• Package-by-package timeline of the eight npm uploads and unpublishes, including version history and registry metadata.
• Full payload walkthrough of the preinstall script, host fingerprinting fields, and Telegram bot exfiltration flow.
• Detection notes and IOCs for lockfiles, npm caches, build logs, and outbound network checks.
• Registry-side response steps for preserving unpublished tarballs and reconstructing affected targets.

👉 Xygeni’s full post includes the payload details, IOCs, 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, and secrets management in the context of real-world access control. It helps security and identity practitioners connect lifecycle controls to the automated systems that now hold privileged access.