RubyGems.org now hosts more than 185,000 published gems with cumulative downloads well past the 300-billion mark, and that scale is precisely why the Ruby ecosystem has become a recurring subject of supply chain security research rather than a footnote to it. Over the past two years, independent researchers, RubyGems.org's own maintainers, and the nonprofit Ruby Central have each published findings or made governance changes that, taken together, form a de facto state-of-the-ecosystem report: dozens of malicious gems quietly distributed for years before detection, a maintainer credential compromise that briefly turned a popular HTTP client into spyware, and a 2025 governance dispute that raised uncomfortable questions about who actually controls the infrastructure Rails shops depend on every day. This report pulls those threads together and looks at what they mean for teams still running Bundler, Gemfile.lock, and native C extensions in production.
A decade of warning signs
Ruby's supply chain problems did not start in 2024. In August 2019, the widely used rest-client gem was compromised after an attacker gained access to a maintainer's RubyGems.org credentials and pushed versions 1.6.10 through 1.6.13 containing a backdoor. The tampered code exfiltrated cookies and environment variables to a remote server and could execute arbitrary commands on any host that installed the poisoned versions — a scenario later cataloged as CVE-2019-15224. In the same window, the strong_password gem was modified to steal a Rails application's secret_key_base and post it to an external endpoint, a technique that, if the key were reused elsewhere, could let an attacker forge session cookies and escalate into full account takeover.
Both incidents shared a root cause that has never really gone away: RubyGems.org, like early npm and PyPI, let any credentialed maintainer push a new version instantly, with no mandatory review, no required multi-factor authentication, and no cryptographic provenance tying a release back to a specific commit or build. Attackers noticed. So did researchers — and by 2024, the pattern had scaled well beyond one-off maintainer account compromises.
The 2024 malicious gem campaign
In March 2024, security researchers publicly disclosed a long-running campaign of malicious RubyGems packages that had evaded detection for years. Roughly 60 gems were identified carrying hidden backdoors, several of them typosquatting or mimicking popular libraries used for Telegram bot automation. Combined, the malicious packages had been downloaded an estimated 275,000 times since as early as 2018, quietly harvesting credentials and, in some variants, rewriting cryptocurrency wallet addresses embedded in outbound messages to redirect payments to attacker-controlled wallets.
What made the campaign notable wasn't sophistication — the payloads were relatively simple string-replacement and exfiltration routines — it was persistence. Six years is a long runway for a malicious package to sit in transitive dependency trees, get pulled into CI pipelines, and ship inside production containers without a single automated scanner flagging it, because static version-pinning and Gemfile.lock hygiene do nothing to stop a gem that was malicious from its very first published version. This is the blind spot that pure lockfile-based dependency management can't close on its own: a lockfile guarantees reproducibility, not integrity.
Governance in flux: the 2025 reckoning
Ruby's supply chain risk isn't purely technical — it's organizational, and 2025 made that unusually visible. Ruby Central, the nonprofit that formally stewards RubyGems.org and Bundler, moved to consolidate direct administrative control over the RubyGems and Bundler GitHub organizations, a decision that stripped repository access from several long-tenured volunteer maintainers with years of commit history on the projects. The dispute became public, drew commentary from prominent figures in the Rails community, and forced an uncomfortable conversation: the infrastructure that resolves every bundle install for every Rails, Sinatra, and Jekyll project on the planet is maintained by a small, under-resourced group whose access-control decisions can change with little public process.
For security teams, governance churn of this kind is a supply chain risk in its own right. Concentration of administrative control — who can merge to RubyGems.org's codebase, who can rotate signing keys, who can push emergency takedowns — determines how quickly a compromised release gets pulled and how much you can trust the registry's own controls in the meantime. It's the same category of risk that npm and PyPI have wrestled with publicly for years, and Ruby's ecosystem is now going through its own version of that reckoning.
To its credit, RubyGems.org has been shipping real hardening in response. Trusted Publishing — OIDC-based authentication that lets CI systems like GitHub Actions publish gems without long-lived API keys — rolled out in 2025, mirroring the model PyPI and npm adopted after their own incidents. RubyGems.org also began phasing in mandatory multi-factor authentication for maintainers of gems above defined download thresholds, closing the exact credential-theft vector that enabled both the rest-client and strong_password compromises.
Why Ruby's dependency model amplifies exposure
Three structural features of the Ruby ecosystem make it harder to contain a bad release once it ships:
- Install-time code execution. Gemspecs can define
extconf.rbscripts and native C extensions that compile and execute code the momentbundle installruns — before any application code, and often before a scanner has a chance to inspect anything beyond the gem's metadata. - Deep transitive graphs concentrated around Rails. A typical Rails application's Gemfile.lock pulls in dozens of indirect dependencies through gems like
activesupport,rack,nokogiri, andloofah. A vulnerability in any one of those — Rack's request-smuggling and denial-of-service CVEs and Nokogiri's recurring libxml2-linked CVEs are the most-patched examples in recent memory — propagates to nearly every Rails app in existence simultaneously. - Long-lived, rarely-audited gems. Many widely-used gems are maintained by one or two people in their spare time, with multi-year gaps between security-relevant releases. That's exactly the profile — as the Ruby Central dispute underscored — where a single compromised or coerced maintainer account can do outsized damage.
None of this means Ruby is uniquely unsafe. It means Ruby's supply chain risk looks structurally similar to npm's circa 2021, and the ecosystem is now living through the same hardening curve — trusted publishing, mandatory MFA, and (still lagging) broader adoption of package provenance and SBOM generation — a few years behind.
What security teams should take from this report
The throughline across the 2019 credential compromises, the 2024 malicious-gem campaign, and the 2025 governance dispute is the same: registry-level trust cannot be the only control standing between a Rails production environment and a malicious dependency. Teams need to know, continuously, exactly which gems (including transitive and native-extension dependencies) are running in each service, whether any of them are actually reachable from executed code paths, and how fast they can rebuild and redeploy if RubyGems.org has to pull a version out from under them.
How Safeguard Helps
Safeguard gives Ruby and Rails teams the visibility that registry trust alone can't provide. Our SBOM generation and ingest pipeline builds a full, accurate inventory of every gem — direct, transitive, and native extension — across your Gemfile.lock, so a RubyGems.org takedown or a disclosure like the 2024 malicious-gem campaign turns into a targeted query instead of a fire drill. Reachability analysis then determines which flagged gems are actually invoked by your application's code paths, cutting through Ruby's deep Rails-centric dependency graphs to separate real exposure from noise. Griffin AI, Safeguard's security-focused model, triages new advisories against your specific codebase and dependency tree, prioritizing what matters instead of surfacing every CVE in every transitive gem. And when a fix is available, Safeguard opens an auto-fix pull request with the vetted version bump already tested against your lockfile, so remediation ships in minutes rather than waiting on the next sprint.