medium

CVE

Not assigned

CWE

CWE-506, CWE-200

Affected Surface

RubyGems package registry, 155 GemStuffer RubyGems package artifacts tracked by Socket, Representative gems and artifacts including lambeth71b, agenda-sample-result, and rubydocran_*, UK ModernGov council portals for Lambeth, Wandsworth, and Southwark, Ruby environments where payload.rb, script.rb, evil.rb, yardload.rb, yard_plugin.rb, exploit.rb, extconf.rb, or fetcher.rb were executed

GemStuffer is a RubyGems registry-abuse campaign disclosed on 13 May 2026. Socket is tracking 155 package artifacts tied to the campaign, all in the RubyGems ecosystem. The activity is unusual because the packages do not appear to be optimized for mass developer compromise; they use RubyGems as an exfiltration and storage layer for scraped data.

The payloads fetch public-facing ModernGov pages used by UK local government councils, package the collected HTTP responses into valid .gem archives, and publish those archives back to rubygems.org with hardcoded RubyGems API keys. RubyGems then becomes the transport and retrieval layer: the attacker can later download the package version and extract the scraped content from the gem archive.

Affected packages and projects

The affected registry and projects are:

  • RubyGems, as the abused package-hosting and exfiltration channel.
  • 155 GemStuffer package artifacts tracked by Socket.
  • Representative gem names and artifacts described in public analysis include lambeth71b, agenda-sample-result, and rubydocran_*-style staging names.
  • UK ModernGov council portals for Lambeth, Wandsworth, and Southwark, which were scraped by the samples Socket analyzed.

RubyGems maintainers separately reported a coordinated spam-publishing campaign from newly registered accounts. SecurityWeek reported that more than 500 junk packages, including packages carrying exploit attempts, were removed and that new account registration was temporarily disabled while RubyGems tightened rate limits and WAF protection. Public reporting says existing RubyGems accounts, existing packages, gem installs, and pushes by existing users were not compromised.

Attack chain

The samples are Ruby scripts rather than conventional dependency payloads. Public analysis describes a repeatable flow:

  1. Collect execution context such as the current time, working directory, script path, and arguments.
  2. Fetch hardcoded council portal URLs with Ruby’s Net::HTTP, including moderngov.lambeth.gov.uk, democracy.wandsworth.gov.uk, and moderngov.southwark.gov.uk.
  3. Extract and follow agenda and committee links such as ieList and mgCommittee paths.
  4. Write the collected responses into a local package tree, commonly under lib/result.txt or a README file.
  5. Build a valid .gem archive.
  6. Push the archive to RubyGems through either the gem push CLI or a direct POST to https://rubygems.org/api/v1/gems.

The credential handling is notable. Some samples create /tmp/gemhome/.gem/credentials, write a hardcoded RubyGems API token, set permissions to 0600, and override HOME so the gem CLI reads the attacker-controlled credential file. Other samples avoid the CLI and include the API token directly in the HTTP Authorization header.

Why this matters

GemStuffer is not the same shape as a typosquat or a maintainer compromise. The immediate victim is not necessarily a developer installing a popular package. The technique matters because it turns a trusted package registry into a covert public data drop.

That has practical security consequences:

  • Egress to rubygems.org often looks normal from developer workstations and CI systems.
  • A .gem archive can hide scraped data inside compressed package contents.
  • Registry publishing may bypass security controls that focus only on package installation.
  • New-account spam can create enough noise to mask more targeted registry abuse.

For application security teams, the lesson is that package registries are bidirectional trust surfaces. Protecting install paths is necessary, but publishing paths and outbound registry API calls also need policy, logging, and least privilege.

Detection

Search for the script names and filesystem artifacts published in Socket’s indicators:

  • payload.rb
  • script.rb
  • evil.rb
  • yardload.rb
  • yard_plugin.rb
  • exploit.rb
  • extconf.rb
  • fetcher.rb
  • /tmp/gemhome/.gem/credentials
  • /tmp/rubydocran_*
  • lambeth71b*
  • lib/result.txt inside unexpected generated gem archives

Network telemetry should flag unexpected POSTs to https://rubygems.org/api/v1/gems, especially from CI jobs or hosts that do not publish gems. Publishing to RubyGems from an application runtime, scraper, or non-release build job should be treated as suspicious.

For Ruby workloads, alert on processes that set HOME to a /tmp path immediately before invoking gem build, gem push, or RubyGems API calls. That pattern is rare in legitimate applications and appears directly in the GemStuffer samples.

Remediation

If a host executed one of the GemStuffer scripts, treat it as an exfiltration incident. Preserve the relevant /tmp staging directories and shell history, then remove the payload and rotate any RubyGems API keys or other credentials available to the process.

Restrict outbound publishing to RubyGems:

  • Allow gem push only from approved release workflows.
  • Block POST requests to rubygems.org/api/v1/gems from CI jobs that do not publish gems.
  • Scope RubyGems API keys to the minimum package set and rotate them regularly.
  • Monitor for new RubyGems credentials written outside expected home directories.

For registry governance, review recently created RubyGems packages in internal dependency mirrors and block newly published external gems until they pass review. The campaign shows that low-download, junk-looking packages can still be useful to attackers when the registry itself is the exfiltration channel.

References