In August 2017, a package called crossenv sat quietly in the npm registry, downloaded by developers who meant to type cross-env, the popular tool for setting environment variables across operating systems. The swap was a single character. On install, crossenv read every environment variable on the machine — API keys, database credentials, CI secrets — base64-encoded them, and shipped them to a server called npm.hacktask.net. It took two weeks for anyone to notice.
That single-character trick has a name: typosquatting. Its cousin, brandjacking, is the broader con of impersonating a trusted name, maintainer, or organization to get developers to trust and install malicious code. Together they're often called name confusion attacks, and they've become one of the most reliable ways to break into a software supply chain — no zero-day required, just a name close enough to fool a tired developer or an automated build. Here's how these attacks actually work, what they've cost real companies, and how to stop trusting names blindly.
What Is a Name Confusion Attack?
A name confusion attack tricks a developer, a build script, or a package manager into installing the wrong package because its name resembles or impersonates a trusted one. There are three overlapping variants worth distinguishing, because they call for different defenses.
Typosquatting exploits typing errors: reqeusts for requests, electorn for electron, crossenv for cross-env. Brandjacking is broader — it's impersonating a known brand, maintainer identity, or organization account (a fake "official" GitHub org, a hijacked maintainer email, a lookalike support domain) to borrow trust rather than just borrow a similar spelling. Dependency confusion is the automated version: attackers publish a public package that shares the exact name of a company's private, internal package, and misconfigured build tooling pulls the public (malicious) version instead because public registries are often checked first or given equal priority. Sonatype's 2026 State of the Software Supply Chain report, analyzing 4,309 malicious open-source packages, found that 91% of brandjacking malware now goes beyond simple typosquatting — meaning the old advice of "just check the spelling" no longer covers most of what's actually happening.
How Did the crossenv Attack on npm Actually Work?
It worked by wrapping the real package so the theft was invisible. The account behind crossenv, publishing under the name "hacktask," didn't just plant a decoy — its package-setup.js script ran once on install, exfiltrated the full contents of process.env via an HTTP POST request, and then quietly installed the legitimate cross-env package underneath it so the tool kept working exactly as expected. Between July 19 and August 1, 2017, the same account published roughly 40 typosquatted packages targeting popular libraries. npm removed crossenv on August 1 after a user flagged the outbound traffic to npm.hacktask.net on Twitter; by then an estimated 50 real developers, not counting mirror bots, had installed it. The lesson that stuck: a typosquat doesn't have to be obviously broken. The most dangerous ones do their job perfectly while stealing everything else.
What Happened in the 2017 PyPI Typosquatting Campaign?
Eleven malicious packages sat live on PyPI for roughly three months, from June to September 2017, before anyone caught them. The campaign shadowed real libraries with near-identical names — urllib instead of urllib3, diango instead of django — and quietly phoned home to a server at 121.42.217.44 with the hostname, username, and package version of every machine that installed them. It wasn't a sophisticated payload; it was reconnaissance, the kind of low-cost data collection an attacker uses to decide which infected machines are worth a second-stage attack. PyPI's response set the template still used today: pull the malicious packages and pre-emptively reserve the names of high-value libraries so the same typo couldn't be squatted twice. That reactive-then-preventive pattern is still how most registries operate — which is exactly why relying on the registry as your only line of defense leaves a gap between publication and takedown that attackers keep exploiting.
How Does Dependency Confusion Turn Brandjacking Into a Full Breach?
It works by exploiting how build tools resolve package names across public and private registries, not by fooling a human at all. In February 2021, researcher Alex Birsan demonstrated this against 35 major companies — including Apple, Microsoft, PayPal, Shopify, Netflix, Tesla, and Uber — by finding the names of their internal, private npm and Python packages (from GitHub commits, forum posts, and leaked dependency manifests) and publishing public packages under those exact names. Because many build systems check public registries by default or give them equal precedence, his code executed inside those companies' own infrastructure. Birsan was paid over $130,000 in bug bounties for the research, including $40,000 from Microsoft alone, because it was that effective.
The technique stopped being theoretical almost exactly two years later. Between December 25 and December 30, 2022, PyTorch's nightly build pipeline was compromised through a malicious package called torchtriton, uploaded to PyPI under the same name as an internal PyTorch dependency. It was downloaded 2,717 times — 2,500 of those on December 26 alone, while most engineering teams were on holiday — and it harvested SSH keys, .gitconfig files, environment variables, and system information from every machine that ran pip install torch during the compromise window. PyTorch's fix was structural, not cosmetic: rename the internal package to pytorch-triton and pre-register the dummy name on PyPI, the same defensive pattern PyPI itself adopted back in 2017.
Why Is Brandjacking Now Bigger Than Simple Typosquatting?
Because it scales better and evades the defenses everyone already built for typos. Sonatype identified more than 454,600 new malicious open-source packages in 2025 alone, pushing the cumulative total of known malware blocked across npm, PyPI, Maven Central, NuGet, and Hugging Face past 1.23 million packages — and of the brandjacking-style malware it analyzed, 91% used tactics beyond simple misspellings: cloned READMEs, stolen maintainer identities, fake verified badges, star-count inflation, and namespace confusion across scopes. The payoff has shifted too — 74% of malicious packages in that analysis targeted developer secrets, environments, or both, not end users. Spell-checking a package name was never going to catch a package that spells its name correctly and steals your .ssh folder anyway.
How Safeguard Helps
Safeguard treats package identity as a security signal, not an assumption. Instead of relying on a developer noticing a missing letter or a security team manually re-registering names after the fact, Safeguard continuously monitors the packages your organization actually pulls in — across npm, PyPI, and other registries — and flags name-similarity risk, newly published lookalikes, and namespace collisions between your internal package names and anything public before they reach a build.
For dependency confusion specifically, Safeguard maps your private package namespace and alerts when a public package registers a matching name, closing the exact gap that let torchtriton and Birsan's research packages execute inside production build pipelines. For brandjacking, Safeguard evaluates maintainer identity signals, publishing history, and behavioral changes in packages you already depend on, since a hijacked or impersonated maintainer account is a bigger 2026 threat than a misspelled name. And because registries only remove malicious packages after they're reported, Safeguard's monitoring runs continuously in your pipeline rather than depending on the registry catching it first.
Name confusion attacks work because trust in the software supply chain still runs on names — package names, maintainer names, brand names. Safeguard verifies what's actually behind the name before your build does.