In February 2021, security researcher Alex Birsan published a disclosure that rattled the software industry: by uploading empty packages with the same names as internal, private dependencies to public registries like npm and PyPI, he'd gotten his code to execute inside the networks of Apple, Microsoft, PayPal, Shopify, Netflix, Tesla, Uber, and roughly 30 other companies. He collected over $130,000 in bug bounties. The technique — dependency confusion — exploited a default behavior baked into nearly every package manager: when a private package name also exists publicly, the resolver often grabs the public one, especially if it has a higher version number.
Five years on, package managers have shipped fixes, enterprises have run tabletop exercises, and "supply chain security" has become a boardroom phrase. But has the underlying problem actually gone away? We looked at what's changed, what hasn't, and where the real exposure sits in 2026.
Is Dependency Confusion Still a Real Attack Vector in 2026?
Yes — the clearest proof is that it kept working after 2021, not just during Birsan's original research. The most consequential public incident came almost two years after the original disclosure: on December 25, 2022, an attacker uploaded a malicious package called torchtriton to PyPI, matching the name of an internal dependency that PyTorch's nightly builds pulled from a private index. Because the public index wasn't excluded, pip fetched the attacker's version instead. For roughly five days, anyone who installed PyTorch nightly builds ran code that harvested SSH keys, exfiltrated /etc/passwd, environment variables, and hostname data to a remote server before uninstalling itself to reduce detection. PyTorch had to publish a full incident report and rename the internal package. This wasn't a proof-of-concept from a bug bounty hunter — it was a live attack against one of the most widely used machine learning frameworks on earth, executed using the exact mechanism Birsan described in 2021.
Did npm and PyPI Actually Fix the Root Cause?
No, not by default — they added optional controls, and adoption of those controls is the gap. npm introduced scoped packages (@yourorg/package-name) and lets organizations reserve scopes, which prevents the specific collision Birsan exploited, but only if teams migrate every internal package to a scope and configure .npmrc to route scoped lookups to the private registry. PyPI has no native concept of private/public namespace separation at all; protection depends entirely on how a company configures pip's --index-url and --extra-index-url flags, and a common misconfiguration — listing the public index as an "extra" source alongside a private one — still lets pip install whichever version number is higher, public or private. Microsoft's own guidance for Azure Artifacts, published after the 2021 disclosure, still has to explicitly warn customers to enable "upstream source" controls because the default multi-source resolution is not safe. In short: the tools got safer, but the safe configuration is opt-in, not the default, in the ecosystems used by the largest share of enterprise codebases.
Are Attackers Still Actively Targeting Specific Companies?
Yes, and the targeting has gotten more deliberate, not less. In 2023, researchers at Checkmarx uncovered a threat actor running a sustained dependency confusion campaign that uploaded malicious packages crafted to match the internal package names of specific, named organizations — including a major German multinational — rather than spraying generic package names and hoping for a hit. That shift matters: it means attackers are now doing reconnaissance to find real internal package names (often leaked through public JavaScript source maps, error stack traces, CI logs, or job postings referencing internal tooling) before crafting a confusion package, which makes the attacks harder to catch with generic typosquatting detection. Separately, Legit Security's 2023 research scanned public source maps and build artifacts across Fortune 500 web applications and found internal package names, some for unpublished private dependencies, exposed in production JavaScript bundles — meaning the reconnaissance step attackers need is often sitting in plain sight.
How Many Enterprises Are Actually Exposed Right Now?
More than most security teams assume, largely because dependency confusion risk is invisible without an explicit audit. Sonatype's annual State of the Software Supply Chain research has tracked a steady rise in malicious and confusion-style packages removed from npm and PyPI each year since 2021, with the cumulative count of malicious packages identified since 2019 surpassing 700,000 by the 2023 report — dependency confusion and namespace-collision packages are a recurring category within that total, not a one-time 2021 spike. The exposure isn't theoretical: it requires only three conditions that are extremely common in large organizations — an internal package name that isn't reserved on the corresponding public registry, a build or CI configuration that queries both public and private registries without strict precedence rules, and no automated check that flags when a dependency's source registry changes unexpectedly. Most enterprises running polyglot dependency trees (npm plus pip plus internal artifact repositories like Artifactory or Azure Artifacts) satisfy all three somewhere in their build pipeline, because the fix requires per-package-manager configuration discipline that's easy to get right once and wrong the next time a new internal library is created.
What Has Actually Improved Since 2021?
Detection and default tooling awareness — the biggest real gain is that "dependency confusion" is now a checklist item instead of an unknown unknown. GitHub's npm registry now supports package provenance attestations and organization-level scope verification, giving teams a way to cryptographically confirm a package came from an expected source. Artifact repository managers like JFrog Artifactory and Sonatype Nexus now ship built-in "virtual repository" configurations specifically designed to enforce private-registry precedence, marketed explicitly in response to the 2021 disclosure. Static analysis and SCA tools have added dependency confusion checks that flag internal package names without a corresponding registry reservation. The gap is that these are all defenses a team has to deliberately turn on and maintain — none of them are ambient protections that work simply because five years have passed since Birsan's blog post.
How Safeguard Helps
Dependency confusion isn't a solved problem — it's a configuration discipline problem that scales badly across large, polyglot codebases with hundreds of internal packages and multiple registries. Safeguard closes that gap by continuously mapping every internal package name your organization uses across npm, PyPI, and internal registries, then automatically checking whether a same-named package exists publicly and whether your build configuration would actually resolve to the private version under real-world conditions — not just in the CI config you wrote once and forgot.
Safeguard also monitors public registries for newly published packages that match your internal namespace, giving you an early warning if someone starts staging a confusion attack against your organization the way Checkmarx documented in 2023. For teams with JavaScript front ends, Safeguard scans production source maps and build artifacts for leaked internal package names — the same reconnaissance surface Legit Security found exposed across the Fortune 500 — so you can close that exposure before an attacker finds it first. The result is that dependency confusion moves from a risk you hope your .npmrc and pip.conf files happen to prevent, to one you can verify, continuously, with evidence.