Found a security issue with RubyGems or RubyGems.org? Please follow these steps to report it.

Reporting a security issue

Before continuing, please ensure this is a security issue for the RubyGems client or the RubyGems.org service. For all vulnerabilities with individual gems, follow our guide on reporting security issues with others' gems. If it's a security issue with the Ruby on Rails framework, see the Rails Security guide.

For any security bug or issue with the RubyGems client or RubyGems.org service, please email security@rubygems.org with details about the problem or submit a report using HackerOne. The RubyGems client library is in scope for bounty reward. You can read the details of the bounty program on the RubyGems HackerOne page.

If you find a compromised or malicious gem, please consider it as a security issue: please email security@rubygems.org with the gem name or submit a report using HackerOne. Note that it is not in scope for bounty reward.

Please note: the rubygems-developers mailing list, the rubygems.org mailing list, and the #rubygems IRC channel are public areas. If escalating to these places, please do not discuss your issue, simply say that you’re trying to get a hold of someone from the security team. Thanks in advance for responsibly disclosing your security issue.

Reporting RubyGems.org Website Problems

If you're having trouble pushing a gem, or otherwise need help with your RubyGems.org account, please open a new help issue.

For bugs or other problems with RubyGems.org, please use the RubyGems.org issue tracker to open a new issue.

Disclosure Policy

RubyGems and RubyGems.org follow a 5 step disclosure policy:

1. Security report received and is assigned a primary handler. This person will coordinate the fix and release process.
2. Problem is confirmed and, a list of all affected versions is determined. Code is audited to find any potential similar problems.
3. Fixes are prepared for all releases which are still supported. These fixes are not committed to the public repository but rather held locally pending the announcement.
4. A suggested embargo date for this vulnerability is chosen.
5. On the embargo date, the rubygems-developers mailing list is sent an announcement. This will include patches for all versions still under support. The changes are pushed to the public repository and new gems released to rubygems. At least 6 hours after the mailing list is notified, a copy of the advisory will be published on the RubyGems.org blog.

This process can take some time, especially when coordination is required with maintainers of other projects. Every effort will be made to handle the bug in as timely a manner as possible, however it’s important that we follow the release process above to ensure that the disclosure is handled in a consistent manner.

Receiving Security Updates

The best way to receive all the security announcements is to subscribe to the rubygems-developers mailing list.

No one outside the core team or the initial reporter will be notified prior to the lifting of the embargo. We regret that we cannot make exceptions to this policy for high traffic or important sites, as any disclosure beyond the minimum required to coordinate a fix could cause an early leak of the vulnerability.

Comments on this Policy

If you have any suggestions to improve this policy, please send an email to security@rubygems.org or open an issue on GitHub. Thanks!