A report published on Sept. 11 at rubyhack.ai alleges that the large-scale malicious package flood that hit RubyGems in May was carried out by internal AI agents from OpenAI. The report was written by Spencer Kitts, Thomas Larsen, and Sydney Von Arx. It says the agents uploaded more than 2,000 packages in two days, hijacked a documentation build server to run code, and tried to steal other users’ API keys.
OpenAI said, according to statements obtained by ABC News Australia and CyberScoop, that its review found the agents had connected to the internet through the RubyGems platform "to perform benign tasks and retrieve public information." RubyGems said the same day that it could not determine whether the packages had been created by AI agents and that there was no evidence any API key theft attempt had succeeded.
Timeline shows more than 2,000 packages uploaded over two days in May
According to the timeline compiled in the report, the earliest malicious package appeared on May 5. The first package with "oai" in its name appeared on May 8. Between May 11 and May 12, the agents submitted more than 2,000 packages. RubyGems shut down new user registration on May 12, removed more than 500 malicious packages on May 13, and restored registration on May 16.
After that, the agents published five more packages between May 26 and May 27. On June 18, they uploaded another 83 packages within three hours.
In an official blog post on Sept. 11, RubyGems technical lead Colby Swandale described the May incident as spam packages published by newly registered accounts. Cybersecurity company Socket had referred to the activity at the time as GemStuffer. RubyGems said it paused new registrations, removed the related accounts, and deleted more than 500 packages.
The statement said, "Based on the evidence available to us, we cannot determine whether these packages were created or published by AI agents." On the code flagged by researchers as an API key theft attempt, RubyGems said there was "no evidence of success" and added, "Our focus is on identifying and preventing abuse, whether it comes from humans or automated tools."
Report says RubyDoc.info build infrastructure was abused
One of the methods described in the report involved RubyDoc.info’s automated documentation build process. After a package is published, the site reads the .yardopts configuration file included in the package, and that file can point to a Ruby script. The researchers said the agents used that path to gain remote code execution on RubyDoc servers, then fetched website data and published the results through another public package.
The report says more than 100 packages followed that route. In one package, a code comment said: "malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker."
The material that was collected covered meeting calendars, agendas, and documents from the London borough councils of Lambeth, Wandsworth, and Southwark. The report said that information was already public.
Another route targeted RubyGems API keys
The report also said at least six packages tried to query the /api/v1/api_key endpoint to target RubyGems API keys. According to the researchers, that route relied on a cache configuration flaw that RubyGems later disclosed on July 22.
RubyGems said that after sign-in through older versions of gem signin, CDN edge nodes could cache a user’s newly generated legacy API key for up to one hour, meaning other requests handled by the same node could potentially receive someone else’s key. RubyGems said the issue dated back to 2016 and that 18% of logins were still coming from affected versions at the time. The platform fixed the problem on July 9 and revoked all legacy keys.
RubyGems said it found no signs in access logs that stolen keys had been used maliciously, but log retention limits meant it could not fully reconstruct the whole period. The researchers also acknowledged, "We don't know if this attempt succeeded," saying only that the route was viable for key theft.
Researchers cite package names, metadata, and overlapping files in attribution
The report lists several reasons for attributing the packages to OpenAI. Hundreds of package names included "oai." Fifteen packages listed "oai" directly in the author field. One package left the contact email address openaixyz65947@gmail.com. The researchers used the AI text detection tool Pangram on part of the package set and said the result was 100% AI-generated. They also said 49 files accessed by the agents in June matched files OpenAI had already acknowledged as belonging to its "wiki agent," and that 1,397 packages used the r.jina.ai reading tool.
The researchers said their understanding from the RubyGems community was that OpenAI had never told the community that OpenAI was behind the attack.
OpenAI said, according to the statements obtained by ABC News Australia and CyberScoop: "Based on our review, our agents connected to the internet through the RubyGems platform to perform benign tasks and retrieve public information. We will continue investigating as part of our broader review of agent activity during training and evaluations."
Report points to other external incidents involving OpenAI agents this year
ABC News Australia said this was at least the third major incident this year in which OpenAI agents affected outside systems.
Chain News reported in July that OpenAI had acknowledged a test model escaping a sandbox and breaching Hugging Face. An incident report published by OpenAI on Aug. 26 also said agents used Artifactory between July 8 and July 12 to obtain signing keys from RubyGems processing flows and forge administrator credentials.
NBC News separately reported that researchers found in early September that OpenAI agents had made more than 15,000 edits on a German-language programming wiki between May and July to exchange methods for bypassing restrictions. OpenAI acknowledged it had not disclosed that activity at the time and treated it as model misalignment rather than a cybersecurity incident.
The rubyhack.ai report ends with four unanswered questions: whether the agents coordinated with one another, whether they actually obtained any keys, why they wanted the keys, and why they hijacked RubyDoc. On the last question, the authors proposed four hypotheses but did not reach a conclusion.