GemStuffer Campaign Abuses 150+ RubyGems Packages to Exfiltrate U.K. Council Data

TL;DR Security researchers identified a campaign called GemStuffer that published over 150 malicious gems to the RubyGems registry, using them as a data exfiltration channel to scrape and archive publicly accessible content from U.K. local government portals. The packages were designed not for mass developer compromise but to fetch council portal pages, package the responses into gem archives, and republish them to RubyGems using hardcoded credentials. The campaign coincides with RubyGems temporarily disabling new account registrations following a separate major attack, though the connection between the two remains unclear.

What happened

Socket researchers identified a coordinated campaign targeting the RubyGems package registry with more than 150 malicious gems. Unlike typical supply-chain attacks that distribute malware to developers, GemStuffer uses RubyGems as a staging ground for exfiltrated data.

The attack workflow is deliberate and repetitive. Malicious gems contain scripts that fetch hard-coded URLs from U.K. local government portals, specifically ModernGov instances used by Lambeth, Wandsworth, and Southwark councils. The scripts collect committee meeting calendars, agenda listings, linked PDF documents, officer contact information, and RSS feed content. These HTTP responses are then packaged into valid gem archives and republished to RubyGems using embedded API credentials.

Socket observed two technical variants. Some payloads create temporary RubyGems credential environments in /tmp, override the HOME environment variable, build a gem locally, and push it to RubyGems using the gem command-line interface. Other variants bypass the CLI entirely and upload archives directly to the RubyGems API via HTTP POST requests. Once published, the attacker can retrieve the scraped data by running a gem fetch command with the gem name and version.

The gems themselves had low adoption. Many carried little or no download activity, and the payloads were repetitive and self-contained, indicating this was not a mass-compromise operation targeting developers.

The timing of this campaign overlaps with RubyGems temporarily disabling new account registration in response to what has been described as a major malicious attack. It remains unclear whether GemStuffer and the registration-disabling incident are related, although Socket noted that GemStuffer fits the same abuse pattern of using newly created packages with junk names to host content.

Why it matters

For developers and infrastructure teams in the MENA region and beyond, this campaign illustrates a novel misuse of package registries. RubyGems is typically thought of as a source of malicious payloads; this attack inverts that threat model by treating the registry as a data storage and retrieval system. Any Ruby developer who installed one of these 150+ gems would have executed arbitrary code that exfiltrated council portal content—an unexpected supply-chain vector.

For defenders monitoring RubyGems or similar registries, the attack demonstrates the need for behavioral analysis beyond signature-based detection. The gems showed repetitive patterns (version increments, hardcoded credentials, repeated gem generation) that, if monitored systematically, could flag abuse earlier.

For government and public-sector infrastructure teams, particularly those operating open data portals, the campaign underscores the risk of systematic bulk scraping. Although the council portal data is publicly accessible, the deliberate, automated archival and exfiltration of it raises questions about what downstream use an attacker might intend.

Affected systems and CVEs

RubyGems registry (150+ malicious gems published)
ModernGov portals (Lambeth, Wandsworth, and Southwark councils targeted)

No CVE assigned at the time of publication.

What to do

Review and audit RubyGems accounts and API credentials for compromise, particularly if your team publishes gems.
Monitor gem publishing activity for patterns consistent with GemStuffer: new accounts publishing multiple gems with minimal download activity, hardcoded credentials embedded in gem code, or rapid version increments.
If you maintain a public data portal (council, government, or otherwise), consider implementing rate-limiting or bot detection on scraping traffic, even if the data is meant to be public.
Review RubyGems security advisories and account registrations for any activity you do not recognize.

Open questions

Is GemStuffer related to the separate major malicious attack that prompted RubyGems to disable new account registration?
What is the attacker's ultimate objective for systematically collecting and archiving council portal data, given that the information is publicly accessible?
Is the campaign registry spam, a proof-of-concept, an automated scraper misusing RubyGems as storage, or a deliberate test of package registry abuse mechanics?
Who is the threat actor behind GemStuffer?
Over what time period did the campaign operate, and how much data was exfiltrated in total?