rubygems.org Now Shows OSV Security Warnings on Gem Pages

On 15 October 2026 the RubyGems team announced that rubygems.org now shows security warnings on gem version pages. The data comes from OSV, which aggregates vulnerability reports from sources including the GitHub Advisory Database, and also carries malicious package reports from the OpenSSF Malicious Packages project. rubygems.org pulls a fresh copy every hour.

This first milestone covers the website only. In the announcement's words, "gem install and bundle install do not change yet." Bringing advisory data into the Compact Index that Bundler and RubyGems read is named as the next milestone.

What's affected

Nothing breaks, but what you see on rubygems.org changes:

• Version pages show a warning or critical alert depending on the advisory's severity, with a short summary and a link to the full report. If several advisories affect one version, each is listed.
• The versions list marks affected older releases with a warning icon.
• Malicious versions reported through OpenSSF's data are labelled as malware.
• Warnings follow the version you are viewing. If the latest release includes the fix, the gem's main page no longer shows the warning.

Two caveats from the announcement are worth repeating. rubygems.org doesn't write or edit advisories; it displays OSV data as is. And "no warning" does not mean the gem is safe. It means OSV has nothing recorded for that version.

For maintainers, corrections reach rubygems.org about an hour after they reach OSV. If an advisory still lists your new release as affected because the fixed version is wrong, the warning will stay on your page until the advisory is corrected. GitHub advisories can be corrected through the "suggest changes" link on the advisory page; malware reports go to the OpenSSF project.

How to check if you're exposed

The website is useful for one-off lookups. For a whole application, query the same OSV data against your lockfile, because the install tools won't warn you yet:

# Every gem and version in a lockfile
bundle exec ruby -e 'Bundler.locked_gems.specs.each { |s| puts "#{s.name} #{s.version}" }'

# Ask OSV about one of them (same data rubygems.org now displays)
curl -s -X POST https://api.osv.dev/v1/query \
  -d '{"package":{"name":"rack","ecosystem":"RubyGems"},"version":"2.2.3"}' \
  | jq -r '.vulns[]? | "\(.id) \(.summary)"'

To scan the whole lockfile in one pass, OSV's own scanner reads Gemfile.lock directly:

osv-scanner scan -L Gemfile.lock

If you already run bundler-audit, keep it. It reads the Ruby Advisory Database, which tracks many of the same issues but is a separate source. Running both shows you where they disagree.

What to do now

1. Don't treat the website as your gate. Until the Compact Index milestone ships, warnings only appear to people who visit the page. Put an OSV or advisory database check in CI against Gemfile.lock.
2. Check malware labels first. A version labelled as malware needs a different response from a vulnerable one: remove it, rotate credentials on any machine that installed it, and review what its install hooks could have done.
3. Upgrade past flagged versions where a fix exists, then confirm the warning disappears for the version you now use.
4. If you maintain gems, audit your advisories. Open your gem on rubygems.org and check that every warning lists the right fixed version. A wrong range now shows up publicly on every affected version page.
5. Watch for the next milestone. When advisory data reaches the Compact Index, Bundler and RubyGems can start reporting it at install time. Plan to wire that output into CI.

Why it matters

Showing vulnerability data next to the package helps the developer who is choosing a gem, at the moment of choice. But it moves responsibility around in ways people miss. The registry displays; it doesn't vet. Advisory quality now matters more, because a wrong fixed version keeps a warning on a safe release, and a missing advisory gives no warning at all.

The bigger change will be the Compact Index work. Once install tools see the same data, a Ruby team's first warning can come from bundle install instead of a separate scanner. Until then, the check has to be something you run yourself.

Try it yourself

Take one Ruby application's Gemfile.lock, run osv-scanner against it, and open rubygems.org for two of the flagged gems. Confirm the website shows the same advisories for the same versions. Then pick one unflagged gem and look it up in the Ruby Advisory Database to see whether both sources agree.

Click through it at your own pace, or open it full screen.

For a quick browser-only check of other ecosystems, the free scan at gold.safeguard.sh/scan accepts package.json, requirements.txt and CycloneDX or SPDX SBOMs. The file never leaves your machine.

Quick check

Sources

• RubyGems Blog: rubygems.org now shows security warnings for gems (15 October 2026)
• OSV API documentation
• OSV-Scanner documentation
• OpenSSF Malicious Packages