RubyGems is the heart of packaging and distributing Ruby libraries (or “gems”). It’s widely used by developers and companies to share code securely and reliably. But in 2022, a subtle bug (CVE-2022-29176) in RubyGems.org’s yank action left parts of the ecosystem open to attack — allowing unauthorized users to remove (“yank”) and even replace certain gems.

In this article, we break down what was vulnerable, how it could have been exploited, how to check if you were affected, and share safe practices for the future.

What Was the Vulnerability?

The issue was with the yank action on RubyGems.org. Normally, only gem owners or those with permission can yank (remove from download) a gem version. Due to a bug, *any* RubyGems.org user could yank or even replace certain gems if they met both of these criteria:

The gem hadn’t been updated for more than 100 days.

So, new gems or “abandoned” dashed-name gems were vulnerable.

References:  
- Official advisory: CVE-2022-29176 Detail
- RubyGems.org Security Blog Post

Let’s do a step-by-step breakdown of a hypothetical exploitation

1. Identify a Target Gem: Attacker finds a gem that has dashes in its name, meets the age criteria, and is publicly available.
 
2. Yank the Gem: Using RubyGems.org’s yank action, the attacker removes an existing version of the gem, even though they are not an owner.
 
3. Push a Replacement: The attacker now pushes a new version of the same gem and version number, but with different (potentially malicious) code.

4. Victims Install the Malicious Gem: Users installing or updating this gem may unintentionally run malicious code.

Simple Exploit Example (Rubygems CLI)

# Attacker yanks a target version (should be owner, but the bug allows anyone):
gem yank my-awesome-gem -v 1.2.3

# Then, attacker creates and pushes a new gem with the same name and version:
gem build my-awesome-gem.gemspec
gem push my-awesome-gem-1.2.3.gem

> Note: This bug has been fixed since May 5, 2022 and is no longer exploitable on RubyGems.org.

1. Audit Your Dependency History

Check your application’s Gemfile.lock. Look for *platform changes* for the same gem version, such as:

- gemname-3.1.2
+ gemname-3.1.2-java


A switch like this with no version change might indicate something suspicious happened.

2. Use Bundler in Safe Modes

Always use Bundler with --frozen or --deployment flags during CI and deployments. These settings lock your dependencies and prevent silent updates, limiting the risk of consuming yanked or replaced gems.

Example in CI

bundle install --deployment --without development test

3. Monitor RubyGems Notifications

Pay attention to RubyGems.org notification emails about your gems being published or yanked. If you see something suspicious, act quickly.

How to Stay Safe

- Prefer solid gems: Avoid relying on poorly maintained or very new gems (as they are easier targets for supply chain attacks).

Use Bundler’s safe modes (--frozen, --deployment).

- Watch for unexpected version/platform changes in Gemfile.lock.

More Technical Reference

- RubyGems.org CVE-2022-29176 Advisory
- NVD Entry for CVE-2022-29176
- Bundler Docs: Deployment Mode

Conclusion

CVE-2022-29176 is a powerful example of how small bugs in software supply chains can open giant doors for potential attackers. The RubyGems.org team responded quickly, patched the vulnerability, and did not find evidence of actual abuse. But it’s a reminder for developers and teams to lock dependencies, audit their supply chain, and monitor for strange gem behaviors.

Stay sharp. Audit your gems. Protect your code.

If you think you might have been affected or need help auditing your gems, reach out or check the official RubyGems support page.

Timeline

Published on: 05/05/2022 22:15:00 UTC
Last modified on: 06/16/2022 15:15:00 UTC