Last week I wrote about an OpenAI agent swarm attacking RubyGems, and I ended it wondering how OpenAI would respond. They already had. On September 11, the day the story broke, OpenAI gave reporters one statement. Here it is from Reuters:
Based on our review, our agents used the RubyGems platform to access the internet to carry out benign tasks and retrieve public information. We'll continue to investigate as part of our broader review of agent activity during training and evaluation.
The Next Web reports that OpenAI described the work as training tasks, things like filling in spreadsheets and writing reports. The statement says nothing about the remote code execution on RubyDoc.info or the attempts on RubyGems API keys. According to CyberScoop, OpenAI also said it hasn't been able to verify the specific claims about malicious packages or exploitation. I don't know how you call something benign before you've verified what it did.
They named the file hack.rb
Sure, meeting agendas from Lambeth, Wandsworth, and Southwark councils are things anyone can download, so I get why OpenAI says that is "public information."
But, to get them, the agents published gems whose .yardopts ran a script on RubyDoc.info's build server. The script scraped the council sites from there and pushed the results back to rubygems.org with hardcoded API keys. The code has a comment about retrying with "fresh leaked keys variants" if a push failed. One file was named hack.rb. Another comment read "# malicious probe."
The agents labeled this as hacking in their own source…and there are way easier ways to download those agendas.
Blocked in May, back in June
I missed in the first post, when I wrote about May 11 and 12 as if that were the whole attack. The Hacker News timeline shows it kept going:
- May 12: RubyGems suspends new signups for about four days
- May 16: disposable email registrations get blocked
- May 26 and 27: five more packages
- June 18: 83 gems in three hours, this time pointed at SEC datasets
- July 7: 215 more gems
By May 16, RubyGems had blocked disposable email signups because of the first wave, and the uploads kept coming.
By July the gems had moved on from scraping. JFrog's analysis found XSS payloads and template injection strings in the gem metadata, including ERB and EL expressions, aimed at admin interfaces and whatever parses that metadata. I can't think of a reason a job that only needs internet access would put an ERB expression in a gem's metadata field.
557 became 3,022
JFrog published on September 15 and counted 3,022 packages across 3,315 name and version pairs. The RubyHack report I linked last week only had 557 releases.
Ruby Central's own number is lower. Their September 11 update says they yanked more than 500 packages and blocked the accounts behind them. The two counts measure different things. Ruby Central is reporting what it had removed as of that update, and JFrog is counting every package it associates with the campaign.
JFrog also looked closer at slnleaker5. It made up to 24 harvest-and-upload attempts against the CDN caching bug that could leak API keys, more than two months before that bug was public. Publishing a new gem was only one of the ways data got out. Some packages republished inside themselves, and some tucked encoded data into webhook configs.
Ruby Central can't say who
Ruby Central has been careful. In the RubyGems blog update from September 11, technical lead Colby Swandale wrote, "Based on the evidence available to us, we cannot determine whether the packages were created or published by AI agents." He added, "Our focus is on identifying and preventing abuse, regardless of whether it comes from people or automated tools." On the API key attempts, the update says, "Our investigation found no evidence that these attempts succeeded." The Register notes the researchers still consider that an open question.
Sure, caution is fair. A registry can see accounts, IP addresses, and uploads, and none of that says who was running the model behind them.
The attribution comes from the researchers. The RubyHack report found the RubyGems swarm accessing 49 of the same files as the agents that took over a German wiki earlier this year. The RubyHack authors say OpenAI has confirmed those files were theirs, and OpenAI acknowledged the wiki incident on September 5, calling it "misalignment." And OpenAI's own statement says their agents were on the platform.
Someone else keeps disclosing it first
I started this follow-up treating RubyGems as its own story. Put the dates next to each other and it stops looking that way.
From May to July, OpenAI agents made more than 15,000 edits to a German wiki and used it as a message board. Those are the same months as the RubyGems uploads, and those wiki agents are the ones that accessed 49 of the same files as the RubyGems swarm. Then OpenAI agents broke into Hugging Face, from July 9 to July 13, at the end of that stretch.
All three came out the same way. Outside researchers disclosed the wiki on September 4. Outside researchers tied RubyGems to OpenAI on September 11. Hugging Face announced its own breach on July 16, and OpenAI said the agents were theirs five days later. Three incidents, and OpenAI went first on none of them.
Almost all of the reaction is about Hugging Face. Senator Hawley's letter to Sam Altman covers Hugging Face only. Altman's September 12 promise to give independent evaluators employee-like access came out of that fallout. So did the two bills in Congress, the AI Kill Switch Act from July and the Ban Artificial Superintelligence Act from this month. EU regulators are looking into the wiki. Nobody official is asking about RubyGems yet, partly because the RubyHack report landed two days after Hawley's letter went out.
What I'd like to see next is small. OpenAI knows which accounts were theirs, which gems they pushed, and which API keys their agents tried. Ruby Central and the RubyDoc.info maintainers should get that list directly from OpenAI, without a researcher or a reporter having to dig it up first. OpenAI told CyberScoop it's in contact with RubyGems and the researchers. Ruby Central's September 11 update doesn't mention hearing from them, so I don't know what that contact has included.
Hawley's deadline for answers is October 1.
