RubyGems account-creation flood + GemStuffer data dead-drops force signup suspension

What happened

On 2026-05-11 Mend Defender flagged more than 120 malicious packages newly published to RubyGems. Within 24 hours the initial cluster ballooned into tens of thousands of gems pushed by thousands of attacker-controlled accounts, forcing RubyGems to suspend new account registration entirely. The actor leveraged a flaw in RubyGems' account-handling systems to create accounts at scale, register API keys against them, and use those keys to upload packages in bulk. The underlying account-creation vulnerability was identified and patched by a Mend.io engineer working with the RubyGems security team; 500+ confirmed-malicious gems were yanked.

Socket independently tracked the data-exfiltration component as GemStuffer: 150+ gems that used the registry itself as an exfiltration channel rather than for malware distribution. The scripts fetch pages from U.K. local-government democratic-services (ModernGov) portals — Lambeth, Wandsworth, and Southwark — collect council calendars, agenda listings, committee links, and related public-meeting content, package the responses into valid .gem archives, and publish those gems back to rubygems.org using hardcoded API keys. In some samples the payload builds a temporary RubyGems credential environment under /tmp, overrides HOME, builds the gem locally, and pushes it.

The published payloads fell into roughly two buckets: empty placeholder gems (likely staging, or noise to overwhelm review) and the GemStuffer data dead-drops. The packages were not designed for mass developer compromise — many had little or no download activity, and the payloads were repetitive, noisy, and unusually self-contained. Socket explicitly flagged the classification as uncertain: it may be registry spam, a proof-of-concept worm, an automated scraper misusing RubyGems as a storage layer, or a deliberate test of package-registry abuse.

RubyGems coordinated with Fastly to enable a web application firewall and tighten rate limiting on account creation, a change it estimated would take two to three days. It reported the malicious spam activity had stopped on 2026-05-13 and that the bot accounts had been blocked and removed; in an update on 2026-05-16 it said the incident was resolved and re-enabled account registrations.

This is a separate event from the 2026-05-01 BufferZoneCorp RubyGems + Go sleeper campaign (multi-2026-05-01-bufferzonecorp-rubygems-go): different actor and method (mass bot-account flood via an account-creation flaw vs a targeted knot-* sleeper) and a different objective (registry-as-dead-drop data exfiltration vs developer-credential theft and Go-module CI tampering). Because the malicious gems were bot-named, mostly empty or data-only, and have been fully yanked, there is no enumerable (name, version) list to pin a lockfile against — this entry is documentation and awareness rather than a scannable package set.

Impact

• RubyGems index abused as a data-exfiltration dead-drop: scraped U.K. local-government portal data published inside valid .gem archives
• Account-creation vulnerability let a single actor mass-register thousands of accounts and API keys, then push gems at scale
• Registry-wide disruption: RubyGems suspended ALL new account sign-ups for ~3 days while Fastly WAF + rate limiting were rolled out
• Low direct developer risk — most gems were empty placeholders or had near-zero downloads and were yanked within 24h; not designed for mass developer compromise
• Trust erosion: hundreds of malicious gems were briefly live in the public index, polluting search and review queues

What to do

1. 1No specific gem to pin: the malicious gems were bot-generated, mostly empty or data-only, and have all been yanked. Typical Gemfile.lock users need take no action
2. 2If you run an internal RubyGems mirror, purge any gems mirrored from accounts created between 2026-05-11 and 2026-05-13
3. 3Audit your own RubyGems account: rotate long-lived API keys and enable MFA
4. 4Treat any gem with no source repository, near-zero downloads, and a freshly-created publisher as suspect before adding it
5. 5Registry operators: rate-limit and WAF-protect account creation; require verified email / MFA before a new account can publish

References

• RubyGems suspends new signups after hundreds of malicious packages are uploaded

  thehackernews.com
  The Hacker News
• GemStuffer campaign abuses RubyGems as an exfiltration channel

  socket.dev
  Socket
• GemStuffer abuses 150+ RubyGems to exfiltrate scraped U.K. council portal data

  thehackernews.com
  The Hacker News
• Hundreds of malicious packages force RubyGems to suspend registrations

  securityweek.com
  SecurityWeek
• Attackers weaponize RubyGems for data dead drops

  darkreading.com
  Dark Reading