Inside the RubyGems Supply Chain Attack: How Mend Defender Caught a Coordinated Flood Before It Spread

On May 11, 2026, Mend Defender flagged more than 120 malicious packages newly published to RubyGems — the standard package manager for the Ruby ecosystem. Within 24 hours, that initial cluster expanded into something far larger: tens of thousands of packages pushed by thousands of attacker-controlled accounts, forcing RubyGems to suspend new account registration entirely while the cleanup got underway.

This is what the incident actually looked like from inside the response — and what every security team running Ruby code should take away from it.

Day one: The first 120 packages

The first wave was detected on Monday, May 11, when Mend Defender — Mend.io’s continuous monitoring system for open-source registries — surfaced a batch of more than 120 packages that did not look like normal publishing activity.

Two behaviors stood out immediately:

– **Outbound beaconing to UK government websites.** A subset of packages, once installed, made requests to UK gov domains. The exact intent of the beaconing is still under analysis; the consistent pattern across many packages is what raised it from “noisy” to “coordinated.”

– **Environment data exfiltration.** Some malicious packages published at this time also included various attempts of XSS and other vulnerability research that seem to be targeting RubyGems rather than RubyGems users. 

Maciej Mensfeld, Principal Product Architect at Mend.io and a member of the RubyGems security team, removed the initial batch as soon as they were confirmed malicious.

That should have been the end of it. It wasn’t.

Day two: A vulnerability and a flood

While investigating *why* a single actor was able to push that many packages so quickly, Maciej identified a vulnerability in RubyGems’ account-handling systems that the attacker was leveraging to spin up accounts at scale. He patched that bug — plus a second, related issue — and prepared the fix for deployment.

The attacker moved faster than the deploy.

In the window before the patch shipped, the malicious actor used the vulnerability to create **thousands** of accounts and register API keys against them. Those API keys were then used to upload **tens of thousands** of packages to RubyGems. The published payloads fell into roughly two buckets: empty placeholder gems (likely staging for later use, or noise to overwhelm review), and gems that — like the original batch — reached out to UK government websites on installation.

The volume and velocity of new account creation, plus the constant flood of package uploads, left RubyGems with one practical option: **shut down new account registration entirely**, freeze the surface, and begin a coordinated cleanup and investigation. That freeze is still in effect at the time of writing.

Why this attack matters

Most coverage of supply chain attacks focuses on a single compromised package — a typosquat, a maintainer account takeover, a malicious version bump. This was different. The attacker wasn’t trying to slip one bad gem past developers. They were trying to **overwhelm the registry’s trust model itself** by generating publishing identities faster than the registry could vet them, then using those identities to seed thousands of malicious artifacts in parallel.

That changes the defender’s problem. CVE feeds don’t help here — none of these gems had CVEs. Reputation signals on maintainer accounts don’t help — the accounts didn’t exist yesterday. The only thing that catches an attack like this in time is **real-time behavioral monitoring of the registry itself**.

The beaconing to UK gov domains is also worth pausing on. Whether the goal was reconnaissance, a staging payload for a later campaign, a misdirection, or something else, the consistent targeting across packages tells you this was not an opportunistic crime-of-convenience drop. Someone planned this.

Mend.io’s role

Mend.io supports RubyGems as part of its broader commitment to open-source supply chain security. In this incident, that wasn’t an abstract commitment — it was the detection layer that surfaced the first 120 packages and the response capacity that removed them before they could propagate further. The majority of malicious package reports filed against RubyGems come from Mend Defender’s continuous monitoring.

The vulnerability that enabled the account flood was identified and patched by a Mend.io engineer working on the RubyGems security team. The ongoing cleanup is being run by the broader RubyGems and Ruby Central response, with Mend.io’s research team continuing to surface malicious uploads as they appear.

This is what software composition analysis looks like when it’s doing real work: not a quarterly scan, not a CVE digest, but a system watching the registry the same way the attackers are — and moving at the same speed.

The bigger picture

The RubyGems incident lands in the same week as the MINI SHAI HULUD campaign against npm and PyPI — a separate, more technically sophisticated operation that compromised 172 packages across 403 versions, attributed to threat actor TeamPCP. The two campaigns are operationally distinct, but the signal they send together is the same: **open-source registries are an active attack surface, and the cadence of attacks is accelerating.**

Supply chain security is no longer a periodic exercise. It is a continuous capability — one that needs to watch every registry your codebase touches, surface anomalies in real time, and move at the speed of the attackers trying to abuse them.