In April 2017, a package called crossenv appeared on npm — one keystroke away from the legitimate cross-env, a tool downloaded millions of times a month to set environment variables across platforms. Anyone who fat-fingered the install command got a package that silently exfiltrated npm credentials and environment secrets to a remote server. That single typo attack pattern has since been replicated thousands of times across npm, PyPI, and — increasingly — the Go module ecosystem, because it exploits something no scanner alone can fix: human muscle memory. Developers type pip install requets or npm install reactt dozens of times a day, and registries with open, unauthenticated publishing let attackers claim the misspelling before anyone else does. This post breaks down how typosquatting actually works across the three major ecosystems, walks through real incidents with dates and numbers, looks at how detection tools like Socket.dev approach the problem, and explains where Safeguard fits in.
What is typosquatting in a package registry, and why does it still work in 2026?
Typosquatting works because package managers resolve names exactly as typed, with no fuzzy-matching safety net, and registries like npm and PyPI allow anyone to publish a new package name in minutes with no identity verification. An attacker registers a name that is a single character off from a popular package — a swapped letter (electorn for electron), a missing hyphen (crossenv for cross-env), a doubled letter, or a homoglyph like a capital I standing in for a lowercase l — and waits for developers, CI scripts, or AI coding assistants to make the mistake. Because npm alone now hosts more than 2.1 million packages and PyPI lists over 550,000 projects, there is effectively infinite namespace for attackers to squat in, and infinite plausible near-misses for any popular library. The payload is usually a post-install script or an __init__.py/setup.py hook that runs automatically on install, before a human ever reviews the code — which is what makes this attack class so much more dangerous than typical phishing.
How big is the typosquatting problem across npm, PyPI, and Go?
It is large and growing every year, with Sonatype's 2023 State of the Software Supply Chain report tallying over 245,000 malicious packages discovered across open source ecosystems that year alone — a 78% jump from 2022 — and typosquatting consistently ranking as one of the top three techniques behind that volume, alongside dependency confusion and account takeover. npm and PyPI bear the brunt because both allow instant, unauthenticated publishing: PyPI's security team has repeatedly had to mass-pause new user registrations and new project creation (most notably for stretches in 2024) specifically to slow down automated typosquat-and-malware campaigns. Go is the outlier. Because Go modules are addressed by full import path (github.com/gorilla/mux, not just mux), classic single-registry typosquatting is structurally harder — but it hasn't gone away, it has shifted to squatting on GitHub usernames and organizations (gorlla, gorilla-mux) and abusing the fact that proxy.golang.org permanently caches whatever version it first fetches, even after the source repository is deleted or renamed.
What do real typosquatting attacks look like?
They look like small, boring, single-file packages that quietly steal credentials or drop a second-stage payload, which is exactly why they survive for weeks before anyone notices. In July 2017, colourama sat on PyPI mimicking the popular colorama terminal-coloring library; it worked exactly like the real thing while a hidden autorun script installed a Windows backdoor pointed at a Bitcoin-wallet-stealing bot. In 2021, JFrog researchers caught jeIlyfish on PyPI — note the capital "I" replacing the lowercase "l" in jellyfish — silently harvesting AWS credentials, SSH keys, and shell history from any machine that installed it. In 2022, Sonatype flagged pymafka, a near-copy of the widely used Kafka client pykafka, which dropped a cryptominer on both Windows and Linux. And crossenv and electorn (both 2017, both npm) remain the textbook cases taught in supply-chain-security training because they show the entire kill chain in miniature: one typo, one install script, full credential exfiltration. Every one of these packages had zero legitimate reason to exist and would have been trivially caught by comparing download counts, publish dates, and maintainer history against the package they were impersonating.
Why is Go module typosquatting different, and why does it matter for enterprises standardizing on Go?
It matters because the attack shifts from the registry to the module proxy cache, and that cache is designed to never forget. When go get fetches a module for the first time, proxy.golang.org and the associated checksum database (sum.golang.org) store that exact version permanently, by design, for reproducible builds. If an attacker gets even one developer to go get github.com/faceboook/react-native-fake before the squat is reported, that malicious version is cached forever — deleting the GitHub repo does nothing to remove it from the proxy. Combined with Go's convention of importing packages under human-readable organization names that are easy to almost-match (googleapi vs googleapis, gogf vs gogo), this makes Go typosquatting a quieter, slower-burn threat than the npm/PyPI pattern of mass publish-and-detect. Enterprises running Go in production services — often exactly the high-value backend and infrastructure code typosquatters want a foothold in — need registry monitoring that treats the module proxy cache as a permanent record, not a transient index.
How are tools like Socket.dev addressing typosquatting today, and where are the gaps?
Socket.dev popularized "deep package inspection" for npm and PyPI — scanning package contents for install scripts, obfuscated code, and suspicious network calls, then surfacing that as a GitHub PR check — and that approach has meaningfully raised the bar for catching typosquats before merge. It works well as a point-in-time gate on pull requests for JavaScript and Python dependencies. The gaps show up at the edges of that model: coverage for Go modules and other ecosystems is comparatively immature, detection is centered on the PR/CI moment rather than continuous monitoring of what's already running in production, and organizations that need typosquat detection tied into broader SBOM, policy, and compliance workflows (SOC 2, vendor risk reviews, audit evidence) end up bolting a separate tool on top. For a security team, that means one alert stream for "does this new dependency look malicious" and a completely different, disconnected process for "can we prove to an auditor what's actually running across every repo and registry we touch."
How Safeguard Helps
Safeguard treats typosquatting detection as one input into a single, continuous supply-chain risk pipeline rather than a standalone PR check. On every dependency change across npm, PyPI, and Go modules, Safeguard runs name-similarity analysis against the top packages in each ecosystem (edit-distance, homoglyph, and substring matching against known-popular names), cross-references publish date, maintainer reputation, and download velocity — the same signals that would have flagged crossenv, colourama, jeIlyfish, and pymafka within minutes of publication — and correlates that with install-script and behavioral analysis of the package contents themselves. Because Go's module proxy cache never forgets, Safeguard specifically tracks proxy.golang.org and sum.golang.org entries as permanent artifacts, flagging typosquatted Go modules even after the source repository has been deleted or renamed, which closes a blind spot most JavaScript/Python-first tools leave open. Findings feed directly into the same SBOM, policy engine, and audit trail Safeguard already maintains for license compliance and vulnerability management, so a typosquat catch isn't a one-off Slack alert — it's evidence in the same continuous record your security team uses for SOC 2 and vendor risk reporting. The result is one pipeline that answers both "is this new dependency safe to merge" and "can we prove what's running in production, and why we trusted it" — without needing a second tool bolted on for the ecosystems your primary scanner treats as an afterthought.