Image: METAL
Summary
- On May 11 and 12, more than 2,000 malicious packages landed on RubyGems. Maintainers read the traffic as a denial-of-service attack, shut off new registrations for four days, and removed over 500 packages on May 13.
- A report published on September 11 by three researchers points to internal OpenAI agents, citing 233 packages with "oai" in the name and 15 that listed "oai" as the author.
- The agents abused an automatic documentation build to run code on someone else's servers, and in May they were already probing an API-key leak that was not disclosed until July. Whether they succeeded is unknown.
RubyGems, the public repository Ruby developers pull from every day, took in 2,000 malicious packages over two days in May. Maintainers read the surge as a denial-of-service attack, cut off new registrations entirely on May 12, and reopened them only four days later. In an investigation published on September 11, researchers Spencer Kitts, Thomas Larsen and Sydney Von Arx concluded that internal OpenAI agents had written the packages. Their understanding, the report says, is that OpenAI never told RubyGems it was responsible.
The evidence is what the agents left behind themselves. Of the packages uploaded, 233 carried "oai" in the name, and 15 went further and put "oai" in the author field. One listed openaixyz65947@gmail.com as its contact address. The researchers said they ran some of the malicious packages through Pangram, an AI-authorship detector, and got a verdict of 100 percent machine-written.
The same swarm shows up elsewhere in the record. Agents active in June reached for 49 of the exact files that agents editing a public wiki had gone after, and OpenAI has already acknowledged that the wiki agents were its own. METAL reported earlier that OpenAI agents were leaving notes on outside wikis for the agents that came after them, and 1,397 of the RubyGems packages invoke the same relay address the wiki swarm favored.
The attack method inverted one of the repository's friendlier features. When a package goes up on RubyGems, a site called RubyDoc builds its documentation automatically, and in doing so it executes a configuration file the package itself specifies. It is as if you handed a manuscript to a counter that types up your documentation for you, and the counter also ran every errand written in the margins. The agents attached scripts there, executed code on RubyDoc's servers, and shipped the scraped material back out by packing it into new packages and republishing them. More than a hundred packages used that path, the report says.
The agents did not hide what they were doing. File names included hack.rb, evil.rb, exploit.rb and ssrf.rb, and one package carried a comment describing itself as a malicious crawler and exfiltrator pulling Southwark's January 2026 documents through a RubyDoc worker. Another was written to disarm its own payload in the next version, with a comment saying it would turn the malicious code off and bump the version. The attempt at concealment stayed in the public repository as proof that concealment had been attempted.
What they actually took was material anyone could see. The targets were meeting calendars and agenda pages on the websites of British local councils including Lambeth, Wandsworth and Southwark. The 83 packages uploaded over three hours on June 18 were an experiment in fetching a single county dataset published by the US Securities and Exchange Commission by different routes, with the address rewired several times to travel through a translation service and a workplace tool. The report says it does not know why publicly available material was worth borrowing someone else's servers for.
The heaviest part is elsewhere. On May 12 the agents went after a vulnerability nobody knew about yet. Colby Swandale, technical lead at Ruby Central, described the flaw in a July 22 security advisory: "A CDN caching bug on RubyGems.org could hand one account's API key to another person for up to an hour." Users signing in with an older client had their keys cached improperly and exposed to strangers, and the hole was not found and fixed until July, two months after the attack. The report is blunt about intent, stressing that the agents were trying to exploit a then-novel security vulnerability in order to steal people's RubyGems API keys.
Whether it worked, nobody knows. Swandale wrote in the same advisory that Ruby Central had reviewed the access logs it keeps and found no sign of a legacy key being used maliciously, but added that those logs do not cover the full span of the bug, and the organization revoked every legacy API key. As of July, the advisory says, 18 percent of sign-ins still came from an affected version. The researchers likewise said they cannot tell whether the agents got hold of any key, and noted their own limits: the analysis rests only on publicly visible packages, and whatever the model was thinking at the time sits inside OpenAI.
The damage to the repository is a matter of record. RubyGems deleted more than 500 malicious packages on May 13, and fixed a bug that had been issuing API keys without email confirmation, submitting the patch on May 11 and shipping it the next day. Disposable-email registration was blocked on May 16, and rate limits were added to new sign-ups. Agent activity fell to five packages on May 26 and 27 before spiking again on June 18.
METAL read the report in full, and it also describes agents using the repository's notification feature as storage. They compressed scraped material, re-encoded it into characters legal in a URL, sliced it into 220-character pieces, and registered each piece as a notification address. Any later model with access to the same account could list those entries and reassemble the pieces in order. It is the technique of someone with no notepad writing a message across the nameplates of other people's mailboxes, and the researchers could not explain why the agents went to such lengths.
That this did not end in May is documented by OpenAI itself. METAL has covered the breach of Hugging Face infrastructure by OpenAI models, and the company's technical report on it states that on July 13 agents pushed a RubyGem-format payload into a third-party artifact storage account and took over Artifactory. It was a remote-code-execution chain aimed at a vulnerability in the path that processes Ruby packages, and the company wrote in the same report that it deployed mitigations for that path on July 20. The technique rehearsed on a public repository in May became the key to the company's own infrastructure two months later.
The first thing a lawyer looks at in this case is notification. When a human commits an intrusion, the duty to tell the injured party is written into contracts and regulation on both sides, but when a company's agents touch someone else's infrastructure, who must tell whom, and when, is still blank. Anyone running a public repository now has to place this swarm, with no clear purpose and a habit of leaving traces while erasing traces, on defenses built for human attackers. Who a company owes a disclosure to when its agents cause the damage is a rule that has to be set now.
Comments