RubyGems After GemStuffer: Audit Owners, Move Publishing to OIDC

OpenSourceChoice verdict: Ruby maintainers should audit gem versions, owners, trusted publishers, webhooks and key history now, then move CI releases to RubyGems Trusted Publishing. Application teams that only install gems do not need to rotate publishing credentials they never had; they should commit lockfiles, add checksums and delay unreviewed releases. Do not treat disputed attribution as the incident-response decision.

This researched response was checked on September 15, 2026. We reviewed current primary sources and independent discussion, but did not inspect an account, reproduce the cache flaw or execute the reported packages.

The decision at a glance

Why this matters now

Ruby Central published a clarification on September 11 about the May GemStuffer campaign. It confirms that newly registered accounts published spam packages, registrations were temporarily disabled and more than 500 packages were yanked. It also says existing gem installs and pushes remained available during the response.

Nightingale Collective's analysis makes broader claims from public package artifacts: more than 2,000 uploads, RubyDoc.info build abuse and attempts to obtain user API keys. The researchers do not know whether the key attempts succeeded. Ruby Central found no evidence that they did and says attribution remains unproven.

That disagreement matters for attribution, not for the control decision. A Hacker News discussion reached 389 points and 330 comments during our check, while a current r/ruby thread added a separate practitioner signal. Attention is high enough to justify a clear runbook; it is not evidence that every Ruby application was compromised.

Separate the three events

First, GemStuffer abused account creation and package publication. This is a package-governance and downstream resolution problem.

Second, researchers report that some packages used .yardopts to run code in RubyDoc.info's builder. That hosted-service boundary is not proof that every developer machine executed the same chain.

Third, RubyGems.org disclosed a legacy-key caching flaw in July. A gzip and CDN-cache interaction could serve one user's full-access key to another caller. It was reported July 6, fixed July 9, and all legacy keys were revoked July 23. Scoped and short-lived Trusted Publishing keys were unaffected.

Existing gem files are immutable: an attacker cannot overwrite the same name, version and platform. A stolen publishing identity can still ship a higher version, yank versions, add an owner, register a publisher or change a webhook. That is why revocation alone is not a complete audit.

Who should act—and who should not

Gem owners need the full audit. An unexplained version, yank, owner, publisher or webhook is an incident even when the current key list looks clean.

Publishing pipelines returning HTTP 401 may hold a revoked legacy key. Replace it with OIDC or an expiring key scoped to one gem and the minimum operation. Do not recreate a permanent full-access key.

Application teams that only consume gems were not holders of RubyGems publishing keys. Their relevant risk is resolving a malicious new release. Our Keyv npm incident runbook applies the same principle: inventory what actually resolved before rotating unrelated secrets.

A measurable owner-and-pipeline audit

Bundler 4 writes checksums into new lockfiles and verifies packaged gems. Add them to existing lockfiles with bundle lock --add-checksums. Cooldown excludes releases newer than a chosen age. Checksums detect artifact changes; cooldown buys review time. Neither proves code is safe.

Pilot Trusted Publishing on one gem

Choose one low-impact gem and its next normal release. Register the exact GitHub repository and workflow, protect release tags, and publish through rubygems/release-gem. Confirm the version, owners, publisher, checksum and downstream staged install.

The pilot passes only when the workflow has no stored RubyGems API secret and a maintainer can explain how to disable the publisher and yank a bad version. If OIDC cannot support the release environment, use a gem-scoped, push-only, expiring key with MFA rather than restoring a legacy credential.

Trusted Publishing removes a stored registry secret; it does not make the workflow trustworthy. A compromised workflow can still publish within its scope. Tie review and provenance to the same protected revision.

Cost, privacy, license and the private-registry option

RubyGems.org remains free public infrastructure operated by Ruby Central. The service code is MIT-licensed; the rubygems-update package lists Ruby and MIT licenses. Each published gem keeps its own license, so registry licensing does not grant rights to dependencies. Our open-source license guide covers that separate review.

The operational cost is staff time for account inventory, workflow migration, dependency review and recovery tests. Gem metadata and package contents are public. Keep secrets and private source out of built gems; OIDC still establishes a CI-to-registry identity.

Gemstash 2.8.2 is worth evaluating for private gems or a controlled cache. It is MIT-licensed and active, but adds a service, database, storage, backups, authentication and patch ownership. A cache can retain a malicious artifact, so self-hosting does not replace the controls above.

Conclusion

The useful response is narrower than the headlines. Publishers should audit persistent account state and prove one OIDC release path. Consumers should harden resolution and inspect what entered their lockfiles.

Ruby Central's remediation closes the disclosed cache path and revoked the affected key class. It cannot prove every account history is clean. Treat attribution as an unresolved reporting question; let versions, owners, publishers, checksums and reproducible releases decide whether your Ruby supply chain passes.

Sources and research record

Sources were accessed September 15, 2026. Dynamic discussion counts are observations from that check.

• Registry response and disputed findings: Ruby Central's September 11 update, May registration incident and Nightingale Collective research.
• Legacy-key vulnerability: RubyGems security advisory and GHSA-9j48-x3c3-mrp2.
• Current release and maintenance: RubyGems 4.0.20 release, client repository, service repository and MIT license and security policy.
• Publishing controls: security guide, Trusted Publishing, API-key scopes and MFA setup.
• Consumer controls: Bundler lock and cooldown reference and Gemfile.lock checksum guide.
• Alternative: Gemstash 2.8.2 package and Gemstash repository.
• Independent interest: Hacker News discussion and r/ruby discussion.