# Leaked RubyGems API Key? Revoke It and Check Your Gems > RubyGems API key exposed on GitHub? Delete it, create a new one, and check every gem version pushed since the leak. Step-by-step guide. Source: https://leakwatch.net/secrets/rubygems-api-key --- [LeakWatch](/) [Product](/product)[Live feed](/leaks)[Guides](/secrets)[Blog](/blog)[Free scan](/) 1. [Home](/) 2. [Secrets](/secrets) 3. RubyGems API Token Code & CI · Secret guide # Leaked RubyGems API Token: what to do in the first hour Critical severityDetected onlyLast verified October 23, 2026 · 4 min read A RubyGems API key lets whoever holds it publish gems under your account. A pushed version can reach every project that installs the gem, which makes this one of the more serious exposures for a library author. The same key can also yank existing versions and manage the list of gem owners. Replace the key, then check what was published while it was public. [Check your GitHub account for leaked secrets — free](/) Provider Rubygems Severity Critical Impact Source code and build access Checked live by LeakWatch No ## What a RubyGems API Token looks like RubyGems API keys start with a fixed prefix, `rubygems_`, followed by a long hexadecimal string: ```text rubygems_…XXXX RubyGems API key (masked) ``` The prefix is distinctive, so a match is rarely a coincidence. The key is usually a single line in a configuration file, which means it is easy to spot once you know what to search for. ## How RubyGems API Tokens get leaked - **The local credentials file.** The `gem` command stores the key in `~/.gem/credentials`. That file is sometimes copied into a dotfiles repository or a backup that is later made public. - **CI variables written into scripts.** A release job that sets `GEM_HOST_API_KEY` inline in a pipeline definition, or prints it while debugging. - **Build and release scripts.** A `Rakefile` or shell script that calls `gem push` with the key typed in. - **Gem metadata and example files.** A key pasted into a README, a sample configuration, or a test fixture that was published with the gem. - **Shared machines.** A key left in a shell history or a configuration file on a machine other people can read. ## What to do in the first hour 1. **Create a replacement key first.** Sign in to RubyGems and open the API keys section of your profile. Create a new key with only the scopes it needs, such as pushing gems, and give it a name that says where it is used. 2. **Update the systems that need it.** Replace the value in your CI secret store and in `~/.gem/credentials` on your own machines, then push a test release to confirm it works. 3. **Delete the exposed key** from the same section. If the page offers a way to reset all keys at once, that also ends every key, including ones you need, so plan for it first. 4. **Review every gem you own.** List the versions of each gem and compare their release dates with the period since the exposure. Any version you did not publish is a serious finding. 5. **Yank unknown versions.** Use `gem yank` on any version you did not publish. Yanking hides it from new installs, but it does not remove it from existing lockfiles and caches, so tell your users what to do. 6. **Check gem owners.** Review the owners of each gem and remove anyone you do not recognize. 7. **Turn on multi-factor authentication** for your account if it is not already enabled, then clean the repository. See [I accidentally pushed an API key to GitHub](/blog/i-accidentally-pushed-an-api-key-to-github) and [deep scan your whole git history](/blog/deep-scan-your-whole-git-history). Not sure what else leaked? [Run a free scan](/). [Not sure what else leaked? Run a free scan.](/) ## Revoke it at RubyGems RubyGems API keys are listed in the API keys section of your profile on RubyGems.org. Find the key by its name, then delete it. Keys work from the moment they are created and stop working as soon as they are deleted. Clearing the local `~/.gem/credentials` file on each machine with `gem signout` removes the copy on that machine, but it does not revoke anything on the server, so delete the key on the site as well. ## How LeakWatch detects it The rule is called “Rubygems API Token”. It looks for the lowercase prefix `rubygems_` followed by exactly 48 lowercase hexadecimal characters, then requires the match to end at a quote, whitespace, a semicolon, a backtick, a line break or the end of the text. The severity is **critical**. This type is not checked live: LeakWatch does not send any request to RubyGems with the key it found. LeakWatch detects this format but does **not** check it live: it can tell you the key is exposed, not whether it still works. Assume it does until you have revoked it. ## FAQ Can someone publish a malicious version with this key? Yes. A push uses the key’s permissions and the gem’s existing owners, so a stolen key can publish a new version that users will install. That is why reviewing the version list is part of the first hour. If I yank a bad version, is the problem gone? Not entirely. Yanking hides the version from new installs, but people who already locked it in a Gemfile.lock or a cache can still get it. Tell your users which version to avoid and what to upgrade to. Does rotating the key affect people who installed my gem? No. Installed gems keep working. The key only controls who can publish new versions, so the risk is future releases and the versions already published during the exposure. ## Related - [PyPI Upload Token](/secrets/pypi-upload-token) - [npm Access Token](/secrets/npm-access-token) - [GitHub Personal Access Token](/secrets/github-personal-access-token) - [I accidentally pushed an API key to GitHub](/blog/i-accidentally-pushed-an-api-key-to-github) - [Which vendors leak most this week](/leaks/trends) - [All secret guides](/secrets) [Get alerted next time a secret leaks — create a free account](/) LeakWatch is not affiliated with Rubygems. ![Gabriel Diyan, founder of LeakWatch](/brand/Photo-Gabriel-Diyan.webp) Gabriel Diyan (0xCr0c0) Cybersecurity student, founder of LeakWatch. I built and run the scanner described here — the detection patterns, the false-positive classifier and the provider validators are mine. [More about who I am](/about). [GitHub](https://github.com/Leakwatch-Scan) · [X](https://x.com/LeakwatchScan) · [LinkedIn](https://www.linkedin.com/in/gabriel-diyan-80a378375) · [GitHub (personal)](https://github.com/crocogab) LeakWatch Secrets leak into public commits every minute. This watches the forges for yours. Built and run by [Gabriel Diyan](/about), a cybersecurity student — [why LeakWatch exists](/about). Scan - [Product](/product) - [Live feed](/leaks) - [Trends](/leaks/trends) - [API docs](/docs) - [CI/CD](/docs?tab=ci) Read - [Blog](/blog) - [Secret guides](/secrets) - [Changelog](/changelog) - [About](/about) Verify - [Security](/security) - [Privacy](/privacy) - [Terms](/terms) - [Legal](/legal) - [Contact](/contact) - [Status](https://status.leakwatch.net) © 2026 LeakWatch [GitHub](https://github.com/Leakwatch-Scan)[X](https://x.com/LeakwatchScan)