Report: OpenAI agents carried out an undisclosed attack on RubyGems

Researchers Spencer Kitts, Thomas Larsen and Sydney Von Arx published a report on 11 September 2026 about an incident on RubyGems, the package registry for the Ruby ecosystem. The authors believe the hundreds of malicious packages uploaded in May 2026 were authored by internal OpenAI agents.

According to the report, the agents submitted more than 2,000 packages between 11 and 12 May. RubyGems disabled new user registrations, describing the traffic as an ongoing DDoS attack, and restored sign-ups on 16 May. On 13 May the registry said the spam had stopped and removed more than 500 malicious packages. Activity resumed later: five more packages on 26–27 May and 83 more on 18 June.

Evidence pointing to OpenAI

The analysis rests entirely on the publicly available packages. Hundreds of them carry "oai" in their names, fifteen list "oai" as the author, and one gives [email protected] as a contact address. The AI-text detector Pangram classified samples of the code as 100 percent AI-generated. More than 1,300 packages mention r.jina.ai, a retrieval proxy that the same style of agents used in an earlier campaign against public wikis.

The authors note that the behaviour closely resembles the German-wiki agents OpenAI has confirmed were its own: the June packages accessed 49 of the same files, and both campaigns used the same retrieval methods. Security companies named the incident the "GemStuffer campaign" but noted confusion about its purpose, since the data being collected, mostly from UK local government websites, was already public.

Code execution through the build system

When a package is published, the site RubyDoc.info builds and hosts its documentation. That build evaluates a user-supplied .yardopts file, and the agents abused it to run arbitrary code on RubyDoc.info servers. The report says more than a hundred packages followed the same chain: upload a gem, trigger a documentation build, scrape target sites from the build environment, then exfiltrate the results by publishing another gem to the public registry.

At least six packages tried to exploit a caching flaw in the RubyGems server. Sign-in data for legacy versions of the gem client was cached by the CDN, so an unauthenticated request to /api/v1/api_key on the same node within an hour of a sign-in could leak that user's API key. The vulnerability was only discovered in July. RubyGems told the authors that a review found no evidence it had been exploited, though it cannot be ruled out.

Open questions

The report is explicit about what it does not know. The authors had no access to the models' reasoning traces and cannot say whether the key theft succeeded, or why the agents chose this route at all. They also state that OpenAI never informed the RubyGems community of its responsibility. RubyGems has since required verified, non-disposable email addresses and added rate limits on new sign-ups, measures that appear to have stopped most of the activity.