RubyGems.org hosts more than 190,000 gems and serves tens of billions of downloads a year, which makes it exactly the kind of high-trust, low-friction ecosystem attackers love to abuse. Twice in the last decade, that trust has been weaponized at scale: once when a cluster of at least 725 typosquatted gems slipped past review and quietly mined cryptocurrency and hijacked wallet addresses on developer machines, and again when the widely used rest-client gem was hijacked outright after its maintainer account was compromised. Both incidents relied on the same blind spot — developers running gem install or bundle install on a name they half-remembered, trusted, or never looked at twice. RubyGems typosquatting isn't a theoretical risk; it has already reached production systems, CI pipelines, and developer laptops. Here's what actually happened, why it keeps happening, and what changes the odds.
What Is RubyGems Typosquatting?
RubyGems typosquatting is the practice of publishing a malicious gem under a name deliberately close to a popular one, betting that a developer will mistype, misremember, or misconfigure their way into installing the wrong package. Classic techniques include single-character substitutions (atlas-client vs. atlas_client), added or dropped hyphens and underscores, homoglyphs, and combinations that read as legitimate forks or extensions ("gemname-utils," "gemname-core"). Because RubyGems, like npm and PyPI, allows anyone to publish a new gem name with no ownership review, there is nothing structurally stopping an attacker from claiming a name that looks 95% right. The malicious payload is usually hidden in the gem's native extension build step or in a post-install hook, so it executes automatically the moment bundle install runs — no require statement, no obvious signal, and often no visible error at all.
How Big Was the 2019 RubyGems Typosquatting Wave?
It involved at least 725 malicious gems, uploaded over roughly four months, with a combined download count researchers estimated at close to 100,000 pulls before RubyGems.org pulled them. The gems were discovered by independent researcher Tute Costa, who noticed a suspicious dependency and traced it back to a much larger pattern: hundreds of gems with names one character off from real, popular libraries. Rather than trying to compromise a specific target, the campaign cast an extremely wide net, uploading typo variants of dozens of common gem names and waiting for accidental installs. The payload was a Windows-only clipboard hijacker: once installed, it silently watched the clipboard for cryptocurrency wallet addresses and swapped them for an attacker-controlled address, so that a victim copying their own Bitcoin or Ethereum address to receive a payment would unknowingly send funds to the attacker instead. One of the gems tied to the same actor, strong_password, had been a legitimate, abandoned project before it was effectively repurposed to carry the malicious code — a preview of the maintainer-hijacking pattern that would resurface a year later.
How Did Attackers Hijack the rest-client Gem in 2020?
They took over the maintainer's RubyGems.org account credentials and used that legitimate access to push malicious updates directly to a gem with over 113 million total downloads. In August 2020, versions 1.6.10 through 1.6.13 of rest-client — one of the most widely used HTTP client libraries in the Ruby ecosystem — were published containing a backdoor. The malicious code exfiltrated environment variables and cookies to a remote server and could execute arbitrary code retrieved from that server on the infected host, effectively giving the attacker persistent remote access to any application that bundled the compromised version. Because rest-client was a transitive dependency for a huge number of Rails applications, the blast radius extended far beyond anyone who had explicitly typed gem install rest-client. The maintainers caught it within days and yanked the versions, but the incident made clear that this class of rubygems supply chain attack doesn't require a clever typo at all — it just requires stealing one password or intercepting one session token from a legitimate publisher.
Why Are Malicious Ruby Gems Hard to Detect?
They're hard to detect because the malicious code usually runs during installation, not during normal application execution, so standard code review of app/ and lib/ directories never sees it. A malicious Ruby gem typically hides its payload in extconf.rb, a Rakefile invoked from the gemspec, or a native extension's compiled artifact — all of which execute with the same privileges as the user running Bundler, before a single line of application code has been loaded. Static analysis tools that scan source trees for vulnerable patterns often skip these installation-time scripts entirely, and CI systems that run bundle install as a matter of course will happily execute the payload with access to CI secrets, cloud credentials, and source code. Version pinning in a Gemfile.lock helps only if the lock file itself was generated after the compromise was already introduced, and most teams don't diff their lock file against a trusted baseline on every change. The net effect is that a single unreviewed bundle update, or a fresh bundle install on a CI runner, can be the entire attack surface.
What Has RubyGems.org Done to Improve Ruby Package Security?
RubyGems.org has progressively tightened account security by requiring multi-factor authentication for maintainers of the ecosystem's most-downloaded gems, phasing MFA in starting in 2022 for gems above defined download thresholds before expanding the requirement more broadly. That directly targets the rest-client scenario, where a stolen or reused password was enough to take over publishing rights to a gem used by millions of applications. The registry has also invested in automated abuse detection to catch bulk uploads of near-duplicate names faster than the four months it took to notice the 2019 wave, and it has discussed trusted-publishing style flows — similar to what PyPI and npm have rolled out — that let CI systems publish gems using short-lived, provenance-linked tokens instead of long-lived API keys. These are meaningful steps for ruby package security at the registry level, but they don't eliminate the underlying problem: a gem name can still be one keystroke away from the one you meant to type, and a compromised maintainer laptop can still push a signed, "legitimate" update.
How Safeguard Helps
Registry-level controls reduce risk, but they don't give an individual engineering team visibility into what's actually running in their own dependency tree today. Safeguard closes that gap by continuously monitoring an organization's RubyGems and Bundler dependencies against known typosquat patterns, flagging new gems with suspiciously similar names to what's already in use, and alerting on gemspecs or install hooks that execute code, fetch remote payloads, or exfiltrate data during installation — the exact mechanism behind both the 2019 typosquatting wave and the rest-client hijack. Rather than relying on a developer to catch a one-character difference in a Gemfile, Safeguard treats every new dependency and every version bump as an event worth evaluating: who published it, does the maintainer account show signs of takeover (a sudden publishing burst after months of inactivity, for instance, is exactly what happened with rest-client), and does the diff between versions introduce behavior that has nothing to do with the gem's stated purpose. For CI and build environments, Safeguard can enforce policy at install time — blocking unreviewed or newly published gems from executing in pipelines that hold cloud credentials — so a compromised or typosquatted package never gets the chance to run with privileged access in the first place. Combined with SBOM generation and provenance tracking across the software supply chain, this gives security and platform teams a concrete answer to the question every rubygems supply chain attack eventually raises: not just "was we affected," but "how would we have known."