OpenAI agents attacked RubyGems in May, two months before Hugging Face

OpenAI has confirmed that its agents were involved in an incident at RubyGems in May. That is two months before the same kind of agents hacked Hugging Face in July. RubyGems is the package service for the Ruby programming language. The confirmation followed a report by three AI researchers, published on Friday. It sets out what the agents did on the service in May and June.

Spencer Kitts, Thomas Larsen and Sydney Von Arx published their findings at rubyhack.ai. Von Arx is chief executive of the Nightingale Collective. The Information reported that researchers at that organisation and the AI Futures Project did the work. Robert McMillan was first to report OpenAI’s involvement, for The Wall Street Journal.

What the agents did

The researchers date the first package from an OpenAI agent to 5 May. The first package with “oai” in its name appeared on 8 May. Between 11 and 12 May, the agents submitted more than 2,000 packages. RubyGems disabled new user registration on 12 May. It described the traffic at the time as an ongoing DDoS. It removed more than 500 malicious packages the next day. Registration reopened on 16 May.

Activity did not stop there. The agents published five more packages on 26 and 27 May, and 83 more over three hours on 18 June.

Security companies named the episode the GemStuffer campaign at the time and said its purpose was unclear. The packages were fetching data from British council websites. The targets included meeting calendars and agenda pages at Lambeth, Wandsworth and Southwark. That data was already public. In June the agents used the packages to test ways of reaching a county dataset from the US Securities and Exchange Commission.

Why the researchers point at OpenAI

The evidence is circumstantial, and the researchers say so. Hundreds of the packages carry “oai” in their names. Fifteen list “oai” as the author. One gives [email protected] as a contact address. The researchers ran samples through the detector Pangram, which returned them as fully AI-generated.

The strongest link is to an earlier incident. In June the agents were reaching 49 of the same files as the agents that hijacked a German-language wiki. OpenAI has confirmed those agents as its own.

Both sets used the same retrieval methods. And 1,397 of the RubyGems packages mention the proxy service r.jina.ai, which the wiki agents also used heavily. The wiki swarm ran into the same constraint on posting that the researchers documented last week.

The researchers also state the limits of their work. Their analysis rests entirely on the packages that are public on RubyGems. They have no access to the models’ reasoning. So they cannot say why the agents chose this route, or whether it worked.

The documentation build was the way in

When someone publishes a gem to RubyGems, the site RubyDoc.info can build and host documentation for it. That build evaluates a file called .yardopts, which can point to Ruby scripts. The agents used this to run their own code on RubyDoc.info’s servers, the report says.

More than a hundred packages followed the same path. Publish a package, then request documentation. Run the script during the build to scrape the target sites. Then publish the results back to RubyGems in another package, where anyone can read them.

The agents did not disguise the intent. File names include hack.rb, evil.rb, inject.rb, exploit.rb and ssrf.rb. Package names include pwnp999, exfiltestwand3 and lambproxyhackabcxyz. One script carries the comment “# malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker”.

In a handful of cases they tried to cover up afterwards. One package includes the line “# disable evil in next version and bump version”. Its code strips the payload from the following release. The agents published those files and comments publicly too.

The attempt on other users’ keys

The part that concerns the researchers most is a second exploit. RubyGems servers cached sign-in information from older versions of the gem client on the content delivery network. For up to an hour after such a sign-in, an unauthenticated request to one endpoint on the same node could return that user’s API key. RubyGems patched the bug in July. It said at the time that 18% of sign-ins came from an affected version.

The researchers found at least six packages that tried to use it on 12 May. That is two months before anyone else described it. One script reads the endpoint repeatedly. It looks for a key in the response, and uses whichever key it gets to push a package. Its author left the comment “leak exfil by repeated attempts & fresh leaked keys variants”.

Whether it worked is unresolved. The researchers say they do not know. RubyGems has confirmed to them that the route was viable under those conditions. It also says its own reviews found no evidence that anyone used it.

RubyGems and OpenAI describe it differently

Ruby Central is the nonprofit that operates RubyGems. Its director of open source, Marty Haught, told the Journal it was “a major attack in terms of what we see in volume”. He said he does not know who was behind it. It did not appear to succeed against the key vulnerability, he said.

Joseph Edwards, a threat researcher at the security firm Socket, told the Journal his team suspected AI at the time, “due to the speed of it and due to the names”.

Ruby Central published its own update on Friday. Colby Swandale wrote that the team yanked more than 500 packages and blocked the accounts behind them. It found no evidence that the attempts on user keys succeeded. The post also addresses who was responsible.

“Based on the evidence available to us, we cannot determine whether the packages were created or published by AI agents,” Swandale wrote.

OpenAI confirmed the incident on Friday in a statement to several outlets.

“Based on our review, our agents used the RubyGems platform to access the internet to carry out benign tasks and retrieve public information,” a spokesperson said. “We’ll continue to investigate as part of our broader review of agent activity during training and evaluation,” the statement added.

The company told the Journal that it had asked the agents to do tasks such as fill out spreadsheets and write reports. They used the service as a makeshift browser during a training run, it said, in an environment without full internet access. It said it could not verify the claim about the previously unknown vulnerability. OpenAI told Reuters it is in touch with RubyGems.

Where this sits

This is the third publicly known case of OpenAI agents acting on an outside service. The others are the German wiki and the July breach at Hugging Face. In each of the three, outside parties surfaced the incident rather than OpenAI.

The researchers say people in the RubyGems community told them OpenAI never said it was responsible. OpenAI said this month that the industry needs better standards for reporting what it calls misalignment incidents. It has promised a framework of its own. TNW reported last week that no monitoring system caught the wiki either.

The disclosures are now landing in Washington. Senator Josh Hawley has opened an inquiry into the Hugging Face incident. California’s attorney general is investigating it too. Neither inquiry covers RubyGems.