A new threat campaign is using RubyGems as a dead drop to store exfiltrated data, but the attacker’s long-term plans are less clear.
Software development security vendor Socket published research concerning a campaign dubbed “GemStuffer,” where an attacker abused the RubyGems package registry “as a data transport mechanism rather than a conventional malware distribution channel,” according to a blog post. RubyGems is a package manager for the Ruby programming language, and acts as a way for developers to distribute Ruby programs or libraries, which are referred to as “gems.”
On the surface, this would look like any number of attacks impacting the open source development supply chain in recent months. There are the Shai-Hulud self-propagating worms, novel ways to compromise open source AI models, and countless attacks against the NPM package ecosystem.
But in this case, the primary victim is unclear, as is the full scope of the threat activity. What organizations need to pay attention to is what the attacker might be planning next and how they can prepare.
GemStuffer Hints at Bigger Attacks
In this case, GemStuffer concerns more than 100 gems that appear to use RubyGems as a dead drop for data rather than to distribute conventional malware. The attackers are publishing a large number of packages with few or even no downloads that contain payloads that are “repetitive, noisy, and unusually self-contained,” according to Socket.
The scripts within the packages merely fetch pages from UK local government portals used by the Lambeth, Wandsworth, and Southwark districts in London; scraped data includes council calendar pages, agenda listings, committee link, and other such public-facing information. This data is then published back to RubyGems as .gem archives through hardcoded API keys.
“In some samples, the payload creates a temporary RubyGems credential environment under /tmp, overrides HOME, builds a gem locally, and pushes it to rubygems.org,” the blog post read. “Other variants skip the gem CLI entirely and POST the archive directly to the RubyGems API.”
The attacker later downloads the package from RubyGems and extracts the data. No command-and-control (C2) server needed.
There are several unusual aspects to this campaign beyond the dead drop piece. For one, this activity was observed at the same time that RubyGems was under attack via an apparent coordinated spam-publishing campaign. Socket did not directly attach this campaign to that threat activity, though the vendor did mention it as having a similar abuse pattern to the spam campaign.
Second, the threat actor created an automated scraper with worm potential, yet they’re using it to scrape public facing data and not putting significant data into these packages to get potential victims to click on them. These gems do not contain conventional malware, but instead data collection tools and scripts for uploading packages using built-in API keys.
It could be a test run against government servers or practice using novel malware, but the motivation is unclear.
“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,” Socket said in its post. “But the mechanics are intentional: repeated gem generation, version increments, hardcoded RubyGems credentials, direct registry pushes, and scraped data embedded inside package archives.”
Feross Aboukhadijeh, founder and CEO of Socket, tells Dark Reading that the threat actor’s technique was clever, but execution was “noisy.”
“That usually points to testing, automation, or spam rather than a mature operation trying to preserve stealth,” he says. “The actor may have cared less about staying hidden and more about proving that RubyGems could be used as a transport layer.”
What Developers Need to Know About GemStuffer
For developers, Socket urged caution because, while none of these 155-plus compromised packages have been downloaded to a significant degree, GemStuffer shows a novel use case for exploiting package repositories (as dead drops). The campaign also serves as an example for why software package registries should not be implicitly trusted.
Organizations that download Ruby packages or believe they may be affected by GemStuffer should audit the /tmp folder on all potentially affected machines; identify the delivery vector if a package is present on a machine (as these gems are not self-propogating); and block outbound gem pushes in CI pipelines that do not publish gems, Socket said.
Aboukhadijeh says the business risk is “less about these specific junk gems being installed and more about what the behavior may be testing.”
“This lands at a time when everyone in supply chain security is already on alert after seeing worm-like campaigns move across multiple ecosystems, including npm, PyPI, and Packagist. Security teams often focus on what packages developers install, but publishing activity needs attention too,” he explains. “Defenders should know which developer machines, CI jobs, and service accounts are allowed to publish to public registries, and they should lock down those publishing workflows so only approved systems can publish approved packages.”
