Over 150 malicious RubyGems identified in a data exfiltration campaign targeting U.K. government portals. Detailed analysis of the GemStuffer attack.
What the GemStuffer Campaign Looks Like
The GemStuffer campaign is a coordinated abuse of RubyGems, the package registry that most Ruby and Rails projects depend on. More than 150 malicious gems were published as part of a single data exfiltration effort aimed at U.K. government portals. Rather than exploiting a flaw in Ruby itself, the attackers relied on the trust developers place in the registry: a gem that installs cleanly and appears to do something useful can also run arbitrary code the moment it is pulled into a build.
The "stuffer" pattern refers to how the payload is packed into otherwise ordinary-looking packages. A gem may carry a legitimate function to justify its existence while quietly bundling logic that reaches out to collect and transmit data. Publishing many packages at once widens the net, increases the odds that at least one gets pulled into a real project, and makes takedown a game of whack-a-mole.
How Malicious Gems Reach a Target
Gems execute code at several points that developers rarely inspect. Native extensions run build scripts during installation, and a gem's own code runs as soon as it is required. That gives an attacker execution inside developer laptops, CI runners, and deployment environments — often the same networks that can reach internal portals and privileged credentials.
Getting a malicious gem adopted usually leans on one of a few tricks:
- Typosquatting — names that closely mimic popular libraries so a mistyped dependency pulls the fake instead.
- Dependency confusion — publishing a public gem that shadows the name of an internal, private package.
- Plausible utility — gems that solve a small, real problem to earn installs before the payload fires.
Why Government Portals Are a Logical Target
Public-sector web portals concentrate exactly what a data exfiltration campaign wants: citizen records, authentication systems, and connections into back-office services. Many of these portals are built on established web frameworks with large dependency trees, so a single poisoned gem deep in the graph can sit far from the code a reviewer actually reads. The gap between "we audited our own code" and "we audited every transitive dependency" is where an attack like this lives.
Exfiltration through a build-time or runtime dependency is also hard to spot after the fact. The malicious traffic can blend in with normal outbound calls a package might legitimately make, and the initial compromise happens in a developer or CI environment that security monitoring often watches less closely than production.
Practical Defenses for Ruby Teams
The core lesson is to treat every dependency as untrusted code that will run with your permissions. Pin exact versions and commit a lockfile so builds are reproducible and a swapped package is visible in a diff. Review new dependencies and version bumps the way you would review your own code, and be especially wary of a brand-new gem, a low-download package, or a name that is one character away from something you already use.
Beyond review, reduce the blast radius: run installs and CI in sandboxed environments with restricted outbound network access, so a gem that tries to phone home has nowhere to send data. Use a curated internal mirror or an allowlist for approved gems, and audit your dependency graph regularly rather than only when you add something new. Detection matters too — unexpected outbound connections from a build agent are a strong signal worth alerting on.