Typosquatting on package registries has been a steady background threat for years, and RubyGems.org has seen its share. 2024 has been a more active year than average, with a cluster of incidents in the first half of the year that exposed some specific weaknesses in how the registry detects and responds. This post is a running ledger of the notable incidents through August 2024, the patterns across them, and what the data suggests about where registry defenses are still thin. The focus is on empirical observation rather than speculation.
The basic dynamic has not changed. An attacker registers a gem with a name that is a minor variant of a popular gem, uploads a version containing malicious code, and waits for confused developers to install the wrong thing. The blast radius depends on how long the gem is live before detection, how many downloads it gets in that window, and whether the malicious behavior is noisy enough to be noticed by endpoint or CI tooling.
The activerecord-postgresql-adapter incident (February 2024)
In early February 2024, a gem named activerecord-postgresql-adapter appeared on RubyGems.org. The gem name is one character different from activerecord-postgres-adapter, an older but still-referenced gem that was itself a variant of the canonical pg gem. The malicious gem was published on February 6 and caught by community flagging on February 9, giving it about 72 hours of exposure.
During that window, it was installed in an estimated 1,100 Bundler runs based on download counts, most of which appeared to be CI systems scanning Gemfile variations or bots indexing the registry. The malicious behavior was an HTTP POST to an attacker-controlled endpoint during gem install, exfiltrating environment variables and the path of the installing user's home directory. The payload was not sophisticated; it relied on the typosquat name landing on a careless copy-paste.
Detection came from a Ruby security researcher who noticed the gem in a routine scan of new registrations and flagged it through the RubyGems.org abuse reporting channel. The gem was yanked within 4 hours of the report. The attacker account was suspended at the same time. A second gem published by the same account, activerecord-postgres-adapter-core, was also yanked. No public analysis has attributed the incident to a specific actor.
The rspec-mocks-helper incident (March 2024)
Late March 2024 brought a gem named rspec-mocks-helper. The legitimate rspec-mocks gem is extremely popular, with over 800 million cumulative downloads, and helper-suffix variants are a common pattern attackers use because developers expect small satellite gems to exist. The malicious gem was live from March 24 to March 27, about 80 hours.
The payload was different from the February incident. Instead of exfiltrating environment variables at install time, the gem included a runtime backdoor that activated only when loaded in a production environment (detected through Rails.env.production?). The backdoor opened a reverse shell to an attacker-controlled endpoint. This made detection harder because development and CI installations showed no malicious behavior, and only production Rails applications that happened to require the gem would trigger it.
The gem was caught when a security-focused Rails consultancy running automated scanning on every gem publication flagged the suspicious network-opening code. The gem was yanked, the account suspended, and notifications sent to the handful of organizations that appeared to have installed it. Download counts suggested about 340 installations over the exposure window, though how many actually reached production is unclear.
The bundler-config incident (May 2024)
In May 2024, a gem named bundler-config was published and remained live for about 11 days before detection, the longest exposure of any 2024 incident. The name is a plausible variant of legitimate Bundler-related gems, and the gem's README was a well-crafted fake that described a real-sounding configuration helper. The attacker had invested time in making the gem look legitimate.
The payload was a post-install hook, invoked through a gem's extensions field, that downloaded a second-stage binary from an S3 bucket and executed it. The binary varied by platform and performed credential theft from common developer locations (git credentials, AWS configuration, npm tokens, some browser profiles). Because it was a compiled binary rather than Ruby source, it was not caught by source-scanning tools that flag common Ruby payloads.
Download counts for the 11-day window suggested about 2,800 installations, which is a larger impact than either of the earlier 2024 incidents. Detection came through an AWS abuse report when the attacker's S3 bucket started serving payload files that AWS security flagged as malicious. RubyGems.org yanked the gem within 2 hours of that report. Several organizations subsequently reported credential-rotation events that appear to have been triggered by this gem.
The webpacker-compiler incident (July 2024)
July 2024 saw a gem named webpacker-compiler published, targeting the now-deprecated webpacker gem that many older Rails applications still use. The gem was live for about 18 hours before being flagged and yanked, one of the shorter exposures of the year. The payload was a simple crypto-mining binary that ran during gem install and persisted via a cron entry.
What makes this incident notable is not the attack itself but the detection path. A GitHub user's Dependabot alert fired on a typosquat detection in their Gemfile.lock change, which was an unusual configuration but showed how community tooling has started catching these. The user reported it to RubyGems.org, which yanked the gem quickly. Download counts suggested only about 90 installations over the exposure window, making this one of the lower-impact incidents of the year.
Patterns across the 2024 incidents
A few patterns emerge when you look at the year's incidents together. First, the median time-to-yank has improved. In 2022, typosquat gems on RubyGems.org had a median exposure of about 6 days. In 2024 through August, the median is about 3 days. This is an improvement but still a long window for an active attack.
Second, the attacker sophistication has increased. The February and July incidents used simple payloads that would have been caught by basic install-time scanning. The March and May incidents used more targeted techniques, environment-specific activation, second-stage binary downloads, that evaded source-only detection. The trend suggests that attackers are learning which detection mechanisms are common and designing around them.
Third, blast radius is concentrated in gems that target CI and bot systems. A large fraction of the download counts in these incidents came from automated systems that are scanning or caching gems, not from intentional installs by developers. This means the raw download number overstates the real exposure. A 1,100-install incident might represent only 100 or so actual compromised developer machines, with the rest being automated systems that install and discard gems quickly.
Fourth, detection is still mostly reactive. Of the four incidents, three were caught by external parties (a researcher, a consultancy, an AWS abuse report, a Dependabot-configured user) rather than by RubyGems.org's own tooling. The registry does run automated scanning on new publications, but the signals it catches are mostly the simpler payloads. More sophisticated attackers design around those signals.
What defenses reliably catch these?
The defenses that have actually caught 2024 typosquat incidents fall into a few buckets. Source scanning of new gem publications, looking for common exfiltration patterns like Net::HTTP calls during install or environment-variable access, catches the simpler payloads. Binary scanning and S3 abuse feeds catch some of the staged-download payloads. Endpoint detection on developer machines catches payloads that make noise post-install. Community vigilance catches the rest, which is a fragile defense because it depends on someone paying attention.
Gemfile-level defenses matter too. A Gemfile that uses explicit version pins and an SBOM-based monitoring system will flag a sudden appearance of a typosquat gem in the dependency tree. Bundler's lockfile, properly used with frozen mode in CI, prevents a typosquat from being silently added by a developer running bundle update. Neither of these catches the initial install on a developer's laptop, but they catch the subsequent spread.
What the registry could do better
The most impactful registry-level change would be automated Levenshtein-distance flagging on new gem registrations. A gem whose name is within edit distance 2 of a top-1000 gem should require manual review before it goes live. This has been discussed in RubyGems.org RFCs for several years and has not shipped, largely because the false-positive rate is hard to tune and the manual-review capacity is limited.
A second useful change would be a pre-install warning in Bundler when a new gem being added has been published recently (within 14 days) and is a name-variant of a popular gem. This would not block the install but would give developers a moment to pause and verify the gem is the one they meant.
Neither of these is a complete fix, and typosquatting will remain an active threat for the foreseeable future. The realistic aim is to keep compressing the exposure window and to make the economics unfavorable for attackers.
How Safeguard Helps
Safeguard continuously monitors your Gemfile.lock against a curated typosquat watchlist updated from community reporting and our own name-distance analysis across RubyGems.org's full gem index. When a new gem appears in your dependency tree that is a close variant of a popular gem you already use, we flag it before the install completes in CI. We track the exposure timeline of known typosquat incidents and correlate them against your installation history, so if your team installed a compromised gem before it was yanked, you find out immediately rather than through a credential-rotation fire drill weeks later.