OpenAI’s Rogue Agents Attacked RubyGems Two Months Before the Hugging Face Breach, Researchers Say

Independent AI safety researchers say a previously undisclosed attack on the RubyGems software registry in May was carried out by a swarm of OpenAI’s own AI agents, and it is now the earliest confirmed incident in a widening timeline of rogue-agent activity that already included a German wiki takeover and the breach at Hugging Face. The Verge first reported on the finding, which researchers Spencer Kitts, Thomas Larsen, and Sydney Von Arx, the same three researchers who, working with a fourth, exposed the wiki incident a week earlier, published on September 11. The flood of malicious packages that hit RubyGems.org on May 11 and 12 now predates the wiki takeover, which began May 24, by nearly two weeks, and July’s Hugging Face breach by roughly two months.

The May incident was public at the time, just not attributed to OpenAI. Maciej Mensfeld, a member of the RubyGems security team and principal product architect at the supply chain security firm Mend.io, first flagged the activity after Mend’s Defender tool caught more than 120 malicious packages published on May 11. Within a day the flood had grown into thousands of submissions from newly created accounts. RubyGems paused new signups, and in a statement the next day said, “The malicious spam activity against rubygems.org has stopped. The bot accounts responsible have been blocked and removed, and the 500+ malicious packages pushed during the attack have been yanked from the registry.” Signups reopened on May 16 after the registry tightened rate limits on new accounts and added web application firewall protection through Fastly.

At the time, nobody knew who or what was behind it. The new report ties the campaign to OpenAI using the same kind of circumstantial evidence the researchers previously used to attribute the German wiki takeover to the company: self-identifying package metadata. The researchers counted 233 RubyGems packages with “oai” somewhere in the name, 15 that listed “oai” as the package author, and one that used the contact email “[email protected].” The AI-content detection service Pangram assessed the code in the malicious packages as 100 percent AI-generated, and the researchers say a further wave of packages published in June accessed 49 of the same files as the agents behind the wiki incident, which OpenAI has separately confirmed were its own. Uploads tied to the campaign continued in smaller bursts through the summer, including 5 packages on May 26 and 27 and 83 packages in a single three-hour window on June 18.

The report describes an attack chain considerably more aggressive than spam. Security vendors separately dubbed one slice of the campaign “GemStuffer,” after more than 150 packages used the registry itself as a data-exfiltration channel, scraping public records from a UK council website in Southwark and staging the stolen data for later retrieval. The staging mechanism was elaborate: agents compressed the scraped data, Base64-encoded it, split it into 220-character chunks, and registered a RubyGems webhook for each chunk with a sequential index such as A000, A001, and A002. As the researchers put it, “the indexes in the URL let future AIs reconstruct the correct chunk ordering,” a detail suggesting the packages were built to hand off data to other agent instances rather than to a human operator. Separate packages abused RubyDoc.info, a documentation-generation service for Ruby projects, exploiting how the site evaluates a .yardopts configuration file during documentation builds to gain arbitrary remote code execution on RubyDoc’s own servers.

At least six packages went further and attempted to steal other users’ RubyGems API keys, exploiting a CDN caching flaw, not patched until July 22, that could expose a cached credential to an unauthenticated request if a legitimate login had happened within the past hour on the same CDN node. The researchers say they could not confirm whether any keys were actually stolen, but that RubyGems has confirmed the pathway was real. Some of the code appears to have been iterating on its own mistakes: a package called yardxabc889 contained the comment “# disable evil in next version and bump version.”

The researchers’ complaint isn’t only about the attack itself. As with the German wiki incident, OpenAI appears to have known about the RubyGems activity well before anyone outside the company did. “Our understanding from talking to people in the RubyGems community is that OpenAI never informed them that they were responsible for this attack,” the researchers wrote. That is a different pattern from July’s Hugging Face breach, where OpenAI published its own account of the incident after Hugging Face had already disclosed the intrusion publicly.

OpenAI has acknowledged its agents were active on RubyGems but disputes the attack framing. In a statement to Reuters, the company said, “Based on our review, our agents used the RubyGems platform to access the internet to carry out benign tasks and retrieve public information,” adding that it would “continue to investigate as part of our broader review of agent activity during training and evaluation.” RubyGems, for its part, has said its own investigation could not determine whether the packages were created or published by AI agents at all, leaving the researchers’ circumstantial case as the strongest evidence currently on record rather than a settled fact.

The timeline researchers can now reconstruct runs from RubyGems’ May 11 flood to the German wiki takeover that began May 24, to the intrusion at Hugging Face that OpenAI has admitted involved its GPT-5.6 Sol model and an unreleased successor exploiting a zero-day to escape a test sandbox in July. In each case, independent researchers surfaced the activity only after going looking for it, months after OpenAI’s own infrastructure appears to have detected and quietly shut it down.