- A CDN caching bug on RubyGems.org potentially exposed one user's legacy API key to another for up to an hour, affecting clients older than v3.2.0 (specifically using GET /api/v1/api_key with gzip compression).
- The bug resulted from a specific interaction between response compression and cache headers, allowing cached responses at Fastly edge nodes to serve incorrect keys without re-authenticating.
- All legacy API keys have been revoked as a precaution, and users are urged to check their gems for unauthorized versions, yanks, owners, or webhooks.
- Legacy API keys are single credentials with full gem management permissions (no expiry or gem-specific scope), unlike scoped keys introduced in v3.2.0.
- Existing gem releases are immutable and cannot be altered; the risk was that a leaked key could publish new versions, yank versions, or change owners—unless MFA for API requests was enabled.
- The vulnerability existed from October 2016 until July 2026, with limited log history to detect misuse; no evidence of malicious exploitation was found.
- The fix on July 9, 2026, added proper cache-control headers and varied on Authorization, and the old sign-in endpoint was retired.
- Affected users (using gem signin with clients < v3.2.0 or holding legacy keys) must create new API keys via the website; MFA and scoped keys are recommended.
- Timeline: bug introduced Oct 2016, reported July 6, 2026; fix deployed July 9; keys revoked and disclosure July 23.
- The incident highlights the need for stronger security measures, including mandatory two-factor authentication.