CVE-2022-29176
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedRubygems is a package registry used to supply software for the Ruby language ecosystem. Due to a bug in the yank action, it was possible for any RubyGems.org user to remove and replace certain gems even if that user was not authorized to do so. To be vulnerable, a gem needed: one or more dashes in its name creation within 30 days OR no updates for over 100 days At present, we believe this vulnerability has not been exploited. RubyGems.org sends an email to all gem owners when a gem version is published or yanked. We have not received any support emails from gem owners indicating that their gem has been yanked without authorization. An audit of gem changes for the last 18 months did not find any examples of this vulnerability being used in a malicious way. A deeper audit for any possible use of this exploit is ongoing, and we will update this advisory once it is complete. Using Bundler in --frozen or --deployment mode in CI and during deploys, as the Bundler team has always recommended, will guarantee that your application does not silently switch to versions created using this exploit. To audit your application history for possible past exploits, review your Gemfile.lock and look for gems whose platform changed when the version number did not change. For example, gemname-3.1.2 updating to gemname-3.1.2-java could indicate a possible abuse of this vulnerability. RubyGems.org has been patched and is no longer vulnerable to this issue as of the 5th of May 2022.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceA authorization bypass in RubyGems.org's yank action allowed any authenticated user to remove and replace certain gems without ownership permissions. The vulnerability affected gems with dashes in their name created within 30 days, or gems with no updates for over 100 days, enabling malicious actors to potentially inject malicious versions of popular gems.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.
NVD · CPE dataall versionsCVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- High
- Privileges
- Low
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- High
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Identify gems with dashes in your dependenciesSearch your Gemfile and Gemfile.lock for gem names containing hyphens (e.g., my-gem, foo-bar)Affected if Your project depends on any gem with a hyphen in its name
-
Check gem creation dates on RubyGems.orgQuery the RubyGems.org API or website for each hyphenated gem to determine its creation dateAffected if Any hyphenated gem in your dependencies was created within the last 30 days
-
Check for stale gem versionsQuery RubyGems.org API to find gem versions with no updates for over 100 daysAffected if Any gem in your dependencies has had no releases or updates for more than 100 days
-
Audit Gemfile.lock for unexpected version changesReview your Gemfile.lock version control history to see if any gem versions changed without corresponding source version updatesAffected if A gem version changed but the declared version in your Gemfile did not change
-
Audit Gemfile.lock for platform changes without version bumpsExamine Gemfile.lock for entries where platform changed (e.g., ruby to java) but version number remained identicalAffected if You see entries like gemname-3.1.2 changing to gemname-3.1.2-java without a version increment
You are affected if your project uses gems with hyphens created within 30 days or gems with no updates for 100+ days, and your Gemfile.lock shows unexpected version or platform changes indicating unauthorized replacement.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scopedUse Bundler in --frozen or --deployment mode in CI and deploys to prevent silent version switches. Audit Gemfile.lock history for gems where platform changed without version number change (e.g., gemname-3.1.2 to gemname-3.1.2-java) as this indicates potential exploitation.
- Verify that RubyGems.org has been patched (the service was patched as of May 5, 2022; no user action required)
- Audit your Gemfile.lock for gems where platform changed without version change (e.g., gemname-3.1.2 to gemname-3.1.2-java) as this may indicate past exploitation
- Use Bundler with --frozen or --deployment mode in CI and during deploys to prevent silent version switches to potentially malicious gem versions
- Review your application's dependency history for any unexpected gem version changes
Generated from the published advisory — verify against the referenced sources before acting.
- Consultation2.0 h
- Implementation1.0 h
- Testing1.0 h
- Review / QA1.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $1,456.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2022-29176 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2022-29176 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data