Microsoft Threat Intelligence has discovered an active supply chain attack involving 33 malicious npm packages that use a technique called dependency confusion to trick developers into installing code that steals credentials and system information. The attack, which unfolded across May 28 and 29, 2026, targeted developers at multiple organizations by impersonating legitimate internal corporate packages.

What Is Dependency Confusion and How Does This Attack Work?

Dependency confusion is a vulnerability that exploits how package managers resolve software libraries. When a developer installs code dependencies, their package manager may accidentally download a malicious public package instead of the intended private internal package, especially if the public version has a higher version number or appears more legitimate. In this case, threat actors registered packages under organizational scopes that mirrored real corporate namespaces, such as @cloudplatform-single-spa, @wb-track, @data-science, and @payments-widget.

The malicious packages were designed to look authentic by spoofing internal infrastructure URLs in their metadata. For example, one package listed a fake GitHub Enterprise repository at git+https://github.cloudplatform-single-spa.io/platform/svp-baas.git and a fabricated Jira bug tracker at https://jira.cloudplatform-single-spa.io/projects/PLATFORM. These details were crafted to pass casual code review and appear legitimate to developers.

How Does the Malicious Code Execute Once Installed?

The attack leverages npm's automatic lifecycle hooks, which allow packages to run code during installation without requiring developers to explicitly import or use the package. When a developer runs npm install, the malicious postinstall script executes automatically in the background. The script is heavily obfuscated using techniques like string array encoding, control flow flattening, and dead code injection to make it difficult for security researchers to analyze.

Once executed, the payload performs reconnaissance by collecting system information, hostnames, environment variables, and developer context. The attack architecture includes a RECON_ONLY flag that is currently set to "1" by default, limiting the payload to information gathering. However, this flag can be toggled server-side by the attacker to enable full exploitation in follow-on attacks, suggesting this is a two-phase operation.

What Specific Tactics Did the Attackers Use to Evade Detection?

The threat actors employed multiple evasion techniques to avoid triggering security alerts. The attack includes CI/CD environment detection and bypass, meaning the malicious code checks for continuous integration and continuous delivery pipeline indicators and silently aborts if detected. This prevents the payload from running in monitored environments where security tooling is more likely to catch anomalous behavior.

The campaign also uses cache-based deduplication to prevent the payload from re-running on every npm install in the same project. A cache directory is created at ~/.cache/_init/, and the stager generates a hash key from the package name, version, and project root path. If a cache entry exists and hasn't expired, the stager exits, reducing the chance of detection through repeated network connections.

The attackers registered packages under three maintainer aliases: mr.4nd3r50n, ce-rwb, and t-in-one. Microsoft's forensic analysis attributes all three accounts to a single operator. Some packages used absurdly high version numbers like 100.100.100 to win npm's package resolution against any real internal package version, while others used more realistic version numbers like 3.5.22 to blend in with legitimate release histories.

How to Protect Your Development Environment

• Audit Your Dependencies: Review your project's package.json and lock files to identify any unfamiliar packages, especially those with high version numbers or published recently. Check the npm registry directly to verify package authenticity and publication dates.
• Configure Package Manager Scopes: Use private npm registries or configure your package manager to require authentication for scoped packages. This prevents your system from accidentally downloading public packages when private ones are intended.
• Monitor Environment Variables: Be cautious about sensitive environment variables like API keys, tokens, and credentials being passed to npm scripts. Limit the information available to postinstall hooks and other lifecycle scripts.
• Enable Security Scanning: Use npm audit and third-party security scanning tools to detect known vulnerabilities and suspicious packages in your dependency tree. Many organizations use Software Composition Analysis (SCA) tools to monitor supply chain risks.
• Review Package Metadata: Before installing a package, verify that the repository URL, homepage, and author information match the official package documentation. Typosquatting and metadata spoofing are common attack vectors.

What Was the Scope of This Attack?

The campaign spanned dozens of scoped packages published under three npm maintainer accounts across nine organizational scopes. The packages targeted specific internal services, with one directly impersonating Sberbank's SberPay payment widget. The threat actors pre-staged some packages weeks in advance, with @t-in-one and @capibar.chat scopes receiving 99.0.7 releases on May 4, 2026, before the main attack bursts on May 28 and 29.

Microsoft's Threat Intelligence team worked with the npm security team to take down the malicious repositories and user accounts. The discovery highlights the ongoing risk of supply chain attacks targeting developers, particularly through package managers where trust and automation intersect. Organizations using npm should review their dependency management practices and consider implementing additional controls to prevent similar attacks.