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

At a glance

What this is: Xygeni describes an npm dependency-confusion cluster that used internal-looking package names, high version numbers, and install-time scripts to fingerprint hosts and beacon to Telegram.

Why it matters: It matters because build systems and developer machines can be exposed the moment a package is resolved, which makes registry trust, private namespace protection, and install-script controls operationally important.

Context

Dependency confusion is a software supply chain failure mode in which a public package with a plausible internal name and a higher version wins resolution over the intended private package. In this case, the security problem is not persistent malware, but install-time execution inside build and developer environments. That makes package namespace hygiene, registry pinning, and script controls part of identity-adjacent governance for workloads and automation.

The article’s first paragraph is about names, not code. Internal-looking package names, paired with semver inflation and zero dependencies, are enough to exploit how package managers choose what to install, which is why DevSecOps teams need to treat naming, versioning, and install hooks as part of the attack surface. The risk is typical of modern npm dependency confusion campaigns, not an isolated curiosity.

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 internal-looking package names with high versions increase supply chain risk?

A: They exploit the assumptions package managers and developers make about namespace ownership and version priority. If private registries are not tightly scoped, a public package with a plausible internal name and a higher semver can outcompete the real dependency and become the code that runs inside the environment.

Q: What are the signs that install-time package hooks are being abused?

A: Look for small zero-dependency packages that run preinstall logic, reach out to external services, or print host-specific data during installation. Unexpected network traffic, especially to messaging or IP-lookup services, is a strong indicator that the package is doing more than dependency setup.

Q: How should DevSecOps teams respond when a public package resolves over a private dependency?

A: Treat it as a supply chain security incident. Preserve build logs and lockfiles, identify where the package was installed, review outbound traffic from the install window, and rotate secrets if the affected environment had access to sensitive credentials or internal systems.

Technical breakdown

How npm package resolution becomes an execution path

npm resolves dependencies before application code runs, which means install scripts can execute as part of the package lifecycle. In dependency confusion, the attacker relies on a public package name colliding with an internal namespace, then publishes a higher version so the package manager prefers it. The danger is not that the package is imported later, but that lifecycle hooks such as preinstall can run immediately during dependency installation. This turns trust in package resolution into code execution risk inside CI runners, build containers, and developer workstations.

Practical implication: Treat package resolution as an execution boundary and restrict install scripts for packages that are not already trusted and pinned.

Why internal-looking names and high semver values matter

The campaign uses Microsoft and Azure-style names, which is the whole point of dependency confusion: the package must look legitimate enough to be selected by humans and by automated resolution logic. High semver values exploit the common assumption that the newest version is the right one, especially when private registries are not isolated or scoped correctly. Zero dependencies and tiny package size reinforce the illusion of harmlessness while making the payload easy to overlook. The mechanism depends on naming, registry behavior, and version priority working together.

Practical implication: Lock private namespaces to internal registries and block public packages that imitate internal module names or outbid them with inflated versions.

Install-time beacons create proof of execution, not persistence

The payload described in the article does not try to stay resident or steal credentials directly. It collects basic host fingerprints, fetches a public IP address, and sends the result through the Telegram Bot API. That is enough to prove the package executed in a real environment and to identify the target host category, such as a CI runner or workstation. The RCE VERIFIED banner is operationally important because it confirms the resolver path was exploitable, which is often the attacker’s primary objective in this class of campaign.

Practical implication: Monitor install-time outbound traffic from package managers and treat any unexpected beaconing during dependency installation as a supply chain incident.

Threat narrative

Attacker objective: The attacker’s objective is to confirm execution inside a real build or developer environment and use that foothold to profile the host for further targeting.

1. Entry occurs when a public npm package with an internal-looking name and inflated version is selected during dependency resolution.
2. Credential or environment exposure follows when the package’s preinstall hook runs inside a build or developer context and fingerprints the host.
3. Impact is achieved when the package beacons host details and execution confirmation to Telegram, giving the operator proof that the target environment resolved and ran the package.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

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

Dependency confusion is a namespace governance problem before it is a malware problem. The attack works because package consumers trust resolution rules that were never designed to distinguish between an internal module and a public imposter with a higher version. That makes package naming, registry scoping, and version governance part of software supply chain security, not just build engineering. Practitioners should treat internal package names as protected assets.

Install-time execution is the control failure, not the payload sophistication. A preinstall hook inside a tiny zero-dependency package is enough to turn ordinary dependency installation into a host reconnaissance event. That means defenders need to focus on lifecycle hooks, not only on static malware signatures, because the actor is using legitimate package-manager behavior as the delivery mechanism. The practical lesson is to reduce trust in install-time scripts.

Build systems need identity-style boundaries for software artifacts. The article’s Microsoft and Azure-style naming pattern shows that resolution trust is functioning as an identity decision for code packages. If private and public namespaces are not isolated, the build process cannot reliably tell who should be allowed to speak for an internal module. Package namespace impersonation: a public package posing as an internal dependency can inherit trust at install time and expose the environment. Teams should govern package identity with the same discipline they apply to privileged service accounts.

Beaconing is often the attacker’s success condition in dependency confusion campaigns. The operator does not need persistence if the install itself proves access and reveals the host class. That changes the detection priority from post-compromise cleanup to prevention at resolution time and outbound-script monitoring. In practice, a successful beacon means the build boundary already failed.

Unpublish does not erase the exposure window. Removing a package from the registry after the fact may reduce future installs, but it does not undo executions already triggered by cached artifacts, lockfiles, or completed CI runs. The governance gap is assuming registry state and exposure state are the same thing. Practitioners should investigate historical installs even when the package is no longer visible publicly.

What this signals

Package namespace impersonation is now a practical build-system control problem. If teams do not govern registry scoping, package naming, and install hooks together, dependency resolution becomes a way to execute unreviewed code inside trusted environments.

The control point has shifted earlier in the lifecycle. By the time a malicious package is removed from the registry, the important question is whether it already ran inside a CI runner, developer laptop, or build container, which means detection needs to start at install time and extend into outbound network monitoring.

For practitioners

• Restrict package resolution to scoped private registries Bind internal package scopes to approved registries and prevent fallback to the public npm registry for modules that represent internal services, SDKs, or telemetry packages.
• Block install scripts for untrusted packages Disable or gate preinstall, install, and postinstall hooks for packages that do not come from an approved allowlist, especially in CI and ephemeral build environments.
• Flag high-version public packages that mimic internal names Alert on packages that combine internal-looking module names with inflated semver values such as 99.x or 99.9.x, because that pattern is a dependency-confusion indicator.
• Hunt for package-resolution evidence across build systems Search lockfiles, npm caches, build logs, and shell history for suspicious package names and installation timestamps, then review outbound requests to unfamiliar endpoints during install.
• Preserve uninstallable artifacts for forensic review Retain metadata, tarballs, and publisher records from unpublished packages so you can reconstruct exposure windows even after public registry entries disappear.

Key takeaways

• Dependency confusion can turn package selection into code execution, which is why registry scoping and install-hook controls matter together.
• High semver values and internal-looking names are not cosmetic in npm campaigns. They are part of the attack logic that helps public packages outrank private dependencies.
• Teams should investigate historical installs, not just current registry state, because unpublish does not erase prior exposure or completed executions.

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 Name Impersonation: A supply-chain technique where a malicious package copies the naming, branding, or expected function of a trusted dependency to earn installation trust. The danger is not only deceptive naming, but the runtime behaviour the package can trigger once installed on a developer or build system.
• Install-Time Beaconing: Install-time beaconing is the use of a package installation script to send host details or execution confirmation to an external service during dependency setup. It is commonly used to verify that a malicious package ran in a real target environment and to collect basic reconnaissance data.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity control to the broader security decisions that shape modern build and automation environments.