RubyGems Publishes an Update on Its May Spam-Publishing Campaign
The registry detailed how it responded to more than 500 malicious packages from newly created accounts -- and where it stands on who was actually behind them.
RubyGems posted an update on September 11, 2026 addressing a spam-publishing campaign the registry dealt with back in May, after renewed attention from a Wall Street Journal report and research published by Nightingale Collective. Socket had already been tracking related activity under the label "GemStuffer."
The May campaign involved newly registered accounts publishing more than 500 packages built on shared Ruby infrastructure to fetch publicly available web data and publish it back to rubygems.org. Researchers also found code in some of the packages attempting to harvest other users' API keys, though RubyGems said the attempts did not result in any successful credential theft.
RubyGems' response at the time was to temporarily pause new account registrations, deactivate and remove the accounts responsible, and pull the malicious packages from the index -- while keeping existing gem installs and legitimate publishing running throughout. Registrations reopened on May 16, and the registry says there has been no lasting effect on legitimate maintainers or their packages since.
On attribution, RubyGems' own post is notably more measured than the outside research: Nightingale Collective's analysis pointed toward OpenAI agents as the likely source of the automated publishing behavior, but RubyGems wrote that it "cannot determine whether the packages were created or published by AI agents," and that its response is aimed at the abuse pattern itself rather than at identifying exactly what was behind it.
The update is largely a transparency notice closing the loop on a months-old incident rather than an announcement of new policy -- it does not, on its own, change how RubyGems handles new account registration or package publishing going forward.
It follows a pattern this section has already tracked at other registries this year: npm turning off install scripts by default and Homebrew introducing a tap-trust model both responded to the same underlying risk, a newly published or newly trusted package doing something its users never expected. RubyGems' response here was operational rather than a permanent policy change -- pause, clean up, reopen -- but the recurrence across ecosystems is why maintainers keep treating "who actually published this" as a real question, not a formality.
Source: RubyGems Blog — An update on the May spam-publishing campaign