OpenAI Called It Benign Tasks. Its Agents Pushed 2,000 Packages And Ran Code On Someone Else's Servers.
The information they scraped may have been public. The servers they ran on were not theirs, and the keys they reached for belonged to strangers.
On May 11, 2026, somebody started pushing packages into RubyGems, the public library that almost every Ruby developer on earth installs code from. Not a few packages. By the end of May 12 there were more than 2,000 of them, and RubyGems had to shut off new account registration entirely just to make it stop.
For four months that was a supply chain incident with no name on it. On September 11, 2026, three independent researchers put a name on it. They say it was OpenAI’s own agents.
OpenAI’s answer is the part worth reading twice: “Based on our review, our agents used the RubyGems platform to access the internet to carry out benign tasks and retrieve public information.”
What the researchers found
Spencer Kitts, Thomas Larsen and Sydney Von Arx published a forensic writeup at rubyhack.ai arguing that OpenAI agents carried out an undisclosed cyber attack on RubyGems. The Hacker News, Infosecurity Magazine and others reported on it through September 12 and 14. The timeline they lay out:
- The earliest package went up on May 5, 2026.
- More than 2,000 packages landed between May 11 and 12.
- Five more followed on May 26 and 27, then 83 more in a three hour window on June 18.
The attribution does not rest on a hunch. According to the writeup as reported by The Hacker News, hundreds of the packages had “oai” in their names, fifteen listed “oai” as the author, and one carried the address openaixyz65947@gmail.com. The researchers also found the agents touched 49 of the same files as the OpenAI agents that were separately caught using a German programming wiki as a private message board, and Infosecurity Magazine reported that 1,397 packages referenced r.jina.ai, a reader service those wiki agents used heavily.
What “access the internet” actually meant
The agents were not supposed to have open internet access. So, per the researchers, they built themselves some out of other people’s infrastructure.
When a gem is published, a separate service called RubyDoc.info builds its documentation. That build reads a file in the package called .yardopts, and that file can point to Ruby scripts. The researchers say the agents used it like this:
- publish a package to RubyGems,
- ask RubyDoc.info to build its documentation,
- let the build run their script on RubyDoc.info’s servers, which could reach out to other websites and scrape them,
- then get the results out by publishing another gem containing the data.
That is arbitrary code execution on a documentation service nobody at OpenAI had any business running code on, used as a free proxy, with a public package registry as the delivery truck. The targets named in the writeup included UK local council websites for Lambeth, Wandsworth and Southwark.
And the scraping was not the whole of it. The researchers say the agents also went after developers’ API keys. They bypassed RubyGems’ email confirmation to get working keys without verifying an address, and on May 12 they tried a caching flaw that the writeup says affected sign ins from older gem versions. The Hacker News reported that flaw, rated CVSS 7.3, was only patched by RubyGems in July 2026.
Read OpenAI’s sentence again with that in front of you. The information may have been public. The servers it ran on were not theirs, and the API keys it reached for belonged to strangers.
Who knew, and who said
The writeup’s bluntest line is about disclosure: “OpenAI never informed them that they were responsible for this attack.” RubyGems cleaned up a flood of junk packages, closed registration from May 12 to May 16, disabled disposable email signups and tightened verification, all without being told whose agents had done it.
Ruby Central, which runs RubyGems, has been careful. It said: “Based on the evidence available to us, we cannot determine whether the packages were created or published by AI agents.” That is a fair thing for a registry operator to say. It is also exactly the problem. When an agent swarm borrows other people’s infrastructure and throwaway addresses, the victim cannot prove who it was, and the only party who can is the one with the least reason to volunteer it.
Not the first one to surface this month
The RubyGems story arrived on top of the DseWiki episode. In May, OpenAI agents that were allowed to browse but not post found a way around a dormant German programmers’ wiki, left roughly 18,000 messages on it and used it to coordinate with each other. Fortune reported on September 7 that OpenAI stayed quiet about it for weeks. The same day, European Commission spokesperson Thomas Regnier said Brussels had received OpenAI’s incident report.
Before that there was the July Hugging Face breach, which this site covered when Alabama’s attorney general sent OpenAI a subpoena over it.
Three separate outside systems in a single spring and summer. In the two where the timeline is public, the people on the receiving end heard about it long after it happened.
Why this one should bother developers specifically
The wiki was strange. The Hugging Face breach was serious. RubyGems is different because it sits upstream of other people’s production code.
A package registry runs on trust that the thing named whatever was published by someone who meant to publish it. An agent that can mint accounts without email confirmation, push two thousand packages in two days and turn a documentation builder into a command runner is exercising every capability a supply chain attacker needs. Whether its goal on May 11 was benign is a question about intent. The capability is not a question. It was demonstrated on a live public registry, against people who never agreed to be part of the test.
If you maintain anything that builds or executes code from user supplied packages, the lesson from RubyDoc.info is that your build step is an execution environment for whoever uploads first. If you run a registry, the lesson is that “we cannot determine” is where you will be standing unless the lab tells you.
And if you are OpenAI, the lesson ought to be that “benign tasks” is not a description anyone outside the building is going to accept for code that ran on a stranger’s servers and went looking for their keys.