The beauty of Ruby’s open source ecosystem lies in its simplicity: add a gem, and you instantly gain powerful new features. But this same convenience can also expose your application to hidden threats. In recent years, attackers have increasingly targeted the supply chain, where dependencies, not code you write, become the weakest link. This post explores how supply chain attacks happen in RubyGems, gives real-world examples, and practical ways to protect your Rails projects.

What Is a Supply Chain Attack?

A supply chain attack occurs when malicious code is injected somewhere in your dependency tree, often through a gem you install, or a dependency of that gem. You trust your gems to behave well, but attackers can exploit that trust by publishing a malicious gem that mimics a popular one, compromising a legitimate gem’s maintainer account, or slipping malicious code into a dependency update. Because gems can run arbitrary Ruby code during installation, a compromised gem can immediately execute harmful actions such as stealing credentials or planting backdoors.

What Supply Chain Attacks Look Like

There are several different ways that attackers attempt to look like the legitimate package they’re trying to spoof to get you to download their malicious code. Here are a few of the most common attacks that an attacker will use:

• Typosquatting: This is when an attacker takes advantage of a user’s misspellings - an attacker publishes a gem with a name similar to a popular, well-known gem using a misspelling, such as misspelling the name or creatively using misspellings (such as lowercase l for I, etc.) to pose as a popular gem, making the user unsuspectingly download the wrong gem.
• Dependency hijacking: A legitimate gem’s account is hacked and updated with malicious code. The gems with the malicious code are downloaded and the malicious code is able to take over.
• Dependency confusion: A malicious package is published in a public repository with the same name as an internal package. The idea is that the client will download the malicious package instead of the correct one.
• Brandjacking: A package is published in the manner that is consistent with the naming conventions or characteristics of a legitimate package in an attempt to get users to download these packages due to them falsely associating them with the brand they trust.

Some warning signs that a gem may be compromised include but are not limited to:

• A sudden, unexplained new release
• Obfuscated or minified Ruby code
• Gems that request network access or handle secrets unnecessarily
• Maintainer changes or ownership transfers with little transparency

rest-client (2019)

In August 2019, a malicious version opens a new window of the popular rest-client gem was published to RubyGems after one of its maintainers’ accounts was compromised. The gem had a backdoor that would activate in Rails installations where Rails.env started with “p” (as in “production”), and downloaded code from a Pastebin.com URL to mine cryptocurrency.

strong_password (2020)

In 2020, a malicious version of strong_password was uploaded opens a new window to RubyGems after one of its maintainers’ accounts was compromised. The hijacked version was found to allow remote code execution on an infected server. It was only found after researcher Tute Costa opens a new window did a routine manual review of Ruby gem dependencies, when he noticed that a version had been published on RubyGems six months after the last release, but no source code changes had been published to the GitHub repository. On further inspection, he found that the gem contained malicious code that could be used to silently trigger remote code execution on an infected server.

Gems posing as plugins to Fastlane CI/CD (2025)

In June 2025, Socket’s Threat Research Team opens a new window reported on two gems that impersonate Fastlane plugins. Fastlane opens a new window is a suite of tools to automate mobile app deployment. The gems in question impersonate legitimate Fastlane plugins that send notifications over Telegram using a bot that posts on a specified channel. The malicious gems are nearly identical to their respective plugins except that they are named and marketed as “proxy” plugins, appearing after Vietnam blocked Telegram opens a new window in May 2025. Developers affected by the ban were the intended targets of this attack. Instead of using a proxy as the gems’ names imply, they instead send sensitive data intended for the Telegram API to a command and control server controlled by the threat actor.

Gems targeting South Korean Grey-Hat Marketers (2025)

In August 2025, Socket’s Threat Research Team opens a new window reported about a long-running supply chain attack targeting South Korean grey-hat marketers that rely on disposable identities and automation tools to run spam, search engine optimization (SEO), and synthetic engagement campaigns. At least 60 malicious gems posing as automation tools for several social media sites, including but not limited to Instagram, Twitter/X, TikTok, WordPress, etc. The gems deliver their advertised functionality but send credentials to threat actor-controlled infrastructure.

As of July, The RubyGems security team opens a new window has neutralized the threat by removing the affected gems. They also publicly shared opens a new window their strategy to detect and remove malicious gems from their system.

How to avoid a supply chain attack

While RubyGems does its best to ensure that malicious packages do not threaten the overall RubyGem ecosystem, it is a resource-intensive commitment and the RubyGems team is not infallible. We all have a duty to protect our systems and ensure that we are not vulnerable to malicious actors.

To avoid supply chain attacks, here are some things you can do:

• Always review the Changelog and diff before upgrading dependencies, especially if the gem is critical to your application.
• Always double-check gem names and sources before installing to ensure you are using the correct version of the gem.
• Use bundler-audit opens a new window , pin versions, and monitor updates closely.
• Regularly audit and lock sub-dependency versions.
• Prefer signed gems and verify checksums or signatures when available.

Enabling Checksum verification in your Gemfile.lock

One way to safeguard your Gemfile.lock from malicious actors replacing the gems you are currently using with unsafe versions is by using the checksum verification introduced in Bundler 2.6 opens a new window . Checksum verification opens a new window ensures that the gems that you download are identical to the ones in your Gemfile.lock. When you run bundle lock --add-checksums, Bundler will add a new CHECKSUMS section to the lockfile. It will then calculates a cryptographic hash for each gem in the lock file and records it. Each time Bundler installs a gem, it recalculates the checksum and compares it to the one that it had already recorded for that gem. If the checksums do not match, Bundler considers the gem tampered and installation is blocked.

Conclusion

Your Gemfile is more than a list of dependencies - it’s a list of potential entry points. Supply chain attacks exploit the trust developers place in open source ecosystems, but by staying vigilant and using the right tools, you can greatly reduce the risk.

Need to upgrade your Rails application? Contact us! opens a new window .