Ruby powers Shopify's checkout, GitHub's core platform, and thousands of Rails applications that move money, health records, and customer data every day. That footprint makes RubyGems.org — home to more than 185,000 gems — a high-value target, not a hobbyist afterthought. In August 2019, attackers used a maintainer's leaked password to push a backdoored version of the rest-client gem that exfiltrated credentials from production Rails apps. In July 2022, a critical flaw in Active Record (CVE-2022-32224, CVSS 9.8) let attackers who could tamper with database rows escalate to remote code execution through unsafe YAML deserialization. In August 2025, researchers found 60 malicious gems, downloaded over 275,000 times combined, quietly stealing developer and social-media credentials. Ruby security isn't one problem — it's dependency integrity, framework-level CVEs, and registry hygiene, all compounding at once. Here's what's actually happened, and what it means for teams shipping Rails and Ruby code today.
What makes RubyGems a supply chain target?
RubyGems is a target because it's a single, high-trust choke point that most Ruby and Rails applications pull from without much scrutiny. The registry hosts over 185,000 gems and has served hundreds of billions of downloads since it launched in 2009, and a huge share of production Rails apps depend on a small set of widely-reused gems — rails, rack, nokogiri, devise, sidekiq — meaning a single compromised maintainer account or hijacked release can ripple through thousands of downstream applications. Unlike a targeted exploit against one company, poisoning a popular gem is a one-to-many attack: publish once, get pulled into every bundle install that follows until someone notices. That asymmetry — low attacker effort, high blast radius — is exactly why RubyGems has seen repeated account-takeover and typosquatting campaigns since 2019 rather than isolated incidents.
How did the rest-client gem get hijacked, and what happened next?
The rest-client gem was hijacked on August 14, 2019, after an attacker reused a password the maintainer had exposed in an earlier, unrelated data breach — a textbook credential-stuffing attack, not a code-level exploit. The attacker pushed versions 1.6.10 through 1.6.13 to RubyGems.org, with 1.6.13 carrying a backdoor that activated specifically when Rails.env started with "p" — targeting production, not development or test. Once active, the malicious code harvested usernames, passwords, and other secrets from the host and sent them to an external domain, and it also had the ability to fetch and execute additional remote code from Pastebin. RubyGems' security team caught it, yanked the malicious versions, and locked the compromised account within roughly two days, by which point the tainted releases had already been pulled around 1,000 times — small in absolute terms, but each pull was a production Rails app with live secrets on the line. The incident (tracked as CVE-2019-15224) became the canonical case study for why gem maintainer accounts need MFA, not just strong passwords.
Why does a single Active Record CVE matter more than a typical dependency bug?
CVE-2022-32224 mattered more than most dependency bugs because it sat in Active Record itself — code running inside nearly every Rails application, not an optional gem a team could simply avoid. Disclosed on July 12, 2022, with a CVSS score of 9.8, the flaw affected all Rails versions before 7.0.3.1, 6.1.6.1, 6.0.5.1, and 5.2.8.1. The root cause: Active Record's serialized columns used YAML.unsafe_load to deserialize stored data by default, so if an attacker could manipulate what got written to a serialized column — through a SQL injection flaw, an admin panel, or any other write path — they could smuggle in a crafted YAML payload that deserialized into arbitrary Ruby objects and achieved remote code execution. The Rails core team's fix switched the default to YAML.safe_load, which only permits a restricted set of classes to be reconstructed. The lesson for security teams wasn't just "patch Rails" — it was that framework-level deserialization defaults can turn a lower-severity bug elsewhere in the app (like SQLi) into full RCE, which is exactly the kind of chained, reachability-dependent risk that a CVE score alone doesn't capture.
Are RubyGems credential-theft campaigns still happening in 2025?
Yes — on August 7, 2025, Socket published research on a coordinated campaign of 60 malicious Ruby gems, published under aliases including "zon," "nowon," "kwonsoonje," and "soonje," that had been live since as early as March 2023 and were downloaded a combined 275,000-plus times before RubyGems.org removed them between July 23 and 28, 2025. The gems posed as automation tools for Instagram, TikTok, X/Twitter, Telegram, Naver, WordPress, and Kakao — mostly aimed at South Korean marketing and social-media automation users — and did deliver the advertised functionality, which is precisely why they went undetected for over two years: the packages worked as promised while quietly exfiltrating credentials to attacker-controlled servers in the background. This follows the same pattern as earlier 2023-2024 campaigns where malicious gems replaced cryptocurrency wallet addresses on the clipboard of infected machines. The throughline across six years of incidents, from rest-client in 2019 to this 2025 campaign, is that functioning, useful-looking code is the most effective camouflage for malware in a package registry — scanning for known-bad hashes alone won't catch it.
What has RubyGems.org actually done to reduce these risks?
RubyGems.org's biggest structural fix has been making multi-factor authentication mandatory for maintainers of the most-downloaded gems, rolling out in phases starting June 2022 and becoming enforced on August 15, 2022. Maintainers of gems that crossed 165 million cumulative downloads began receiving mandatory reminders, and once a gem passed 180 million downloads, MFA became a hard requirement — without it, the maintainer lost the ability to push or yank gems, manage co-owners, or edit their profile until they enabled it. RubyGems framed the move around the well-documented finding that MFA blocks roughly 99.9% of automated account-takeover attempts, directly targeting the exact failure mode behind the 2019 rest-client compromise. It's a meaningful floor-raiser, but it's also an admission of scope: MFA protects against stolen credentials, not against a legitimately-authenticated maintainer publishing malicious code on purpose, or a typosquatted package that never had a real maintainer account to protect in the first place — which is why the registry has kept seeing incidents like the 2025 campaign even after the mandate took effect.
How Safeguard Helps
Safeguard treats Ruby and Rails dependency risk as a call-path problem, not a checklist problem. Reachability analysis traces whether a vulnerable method in a flagged gem — like the YAML deserialization path behind CVE-2022-32224 — is actually invoked by your application code, so teams stop burning sprint time patching Active Record CVEs that no controller in their codebase can reach. Griffin AI reviews new and updated Gemfile.lock entries against behavioral and provenance signals — the same kind of anomalous, working-but-malicious pattern that let the 2025 Socket-reported gems evade detection for two years — and flags suspicious publishes before they land in a build. Safeguard also generates and ingests SBOMs across your Ruby services so you have an accurate, current inventory the moment a gem like rest-client or nokogiri gets a new advisory, and it opens auto-fix pull requests that bump the affected gem to a patched version with the diff and changelog attached, so remediation is a review-and-merge instead of a manual Bundler audit.