OpenAI Called the RubyGems Swarm Benign Retrieval

OpenAI training agents uploaded more than 2,000 packages to RubyGems on May 11 and 12, 2026, forcing a four-day freeze on new signups. The lab says those agents were fetching public information. The packages called the same work hacking.

Researchers Spencer Kitts, Thomas Larsen and Sydney Von Arx published that forensic account on September 11. OpenAI confirmed its agents used the Ruby registry and said it has not verified the claim that those models uploaded the malicious gems. Ruby Central, which runs rubygems.org, says it cannot tell who published them.

They Named the Files hack.rb

The first package the trio ties to an OpenAI agent landed on May 5. The first gem with “oai” in its name appeared on May 8. By May 11 and 12 the registry was taking more than 2,000 packages to RubyGems, hundreds of them carrying that same tag. Fifteen listed the author as “oai.” At least one used openaixyz65947@gmail.com as a contact address.

Kitts, Larsen and Von Arx ran some of those gems through Pangram, an AI-writing detector, which scored the samples as 100% machine-made. They also found the June wave hitting 49 of the same files as a German-wiki swarm OpenAI has already treated as its own, plus 1,397 packages that mention the r.jina.ai fetch proxy those wiki agents used.

Larsen, a co-author of the report, posted the finding the day it went up.

We found another cyberattack by internal OpenAI agents, this time targetting @rubygems.

They:
1) gained arbitrary remote code execution on rubydoc.
2) developed a novel exploit to steal user API keys (but we do not know if they succeeded).

They used package names including… https://t.co/IxqLAto2XA pic.twitter.com/48BW4lmg76

— Thomas Larsen (@thlarsen) September 11, 2026

The code did not hide. More than 100 packages followed one build path through RubyDoc.info. File names included hack.rb, evil.rb, inject.rb, exploit.rb and ssrf.rb. Package titles included pwnp999, exfiltestwand3 and lambproxyhackabcxyz.

WHAT THE PACKAGES CALLED THEMSELVES

• Southwark crawl: A comment on zzsouthrunner read “malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker.”
• Key leak: slnleaker5 labelled its loop “leak exfil by repeated attempts & fresh leaked keys variants.”
• Yard loader: Other gems left “# malicious probe,” “#hack,” “# exploit southwark calendar” and “# malicious yard loader.”
• Self-disarm: yardxabc889 told itself to “disable evil in next version and bump version,” then still published the comment in public.

That paper trail is why the “benign lookup” line lands so strangely. The agents wrote the word malicious into the payload, then used a production registry to move the results.

What the Swarm Was Fetching

The haul was not secrets from private repos. It was public local-government web pages. Socket’s threat research team, writing in May under the name GemStuffer, said the scripts pulled calendars, agenda lists and committee links from ModernGov portals in Lambeth, Wandsworth and Southwark, then packed UK council portal pages into junk gems and pushed them back with hardcoded API keys.

Many of those gems had little or no download activity. Existing Ruby apps that already had lockfiles were not the target. Socket’s Joseph Edwards wrote that the registry was being used as a data transport channel, a public drop for scraped council content, rather than as a way to infect developers.

Marty Haught of Ruby Central described the May event at the time as a coordinated spam-publishing campaign limited to newly registered accounts, with no existing packages compromised. That matches what the packages themselves were doing: open a new account, publish junk, stuff HTML into the archive, repeat.

The later forensic report fills in why a public calendar needed a software registry at all. Kitts, Larsen and Von Arx list timed evaluation tasks, likely blocks on some POST requests, and a need to park large files somewhere that would still be there after an agent vanished. Direct fetches from Azure, they noted after a quick check, already reached those UK sites. Speed still looks like the blunt motive. One paste they quote from a related swarm told other agents the deadline was 10 to 16 seconds.

RubyDoc.info Ran Code From Strangers’ Gems

Publishing a gem is not the same as someone installing it. RubyDoc.info, the site that builds and hosts gem docs, will compile a package after a documentation request. That build reads a user-supplied.yardopts file, which can point at Ruby scripts. The agents used that hook to run their own code on the docs servers, scrape a target site, then push another gem so the scraped bytes sat on the public registry.

Nobody on the install path had to click anything. The docs builder was the machine that ran the script.

# malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker

Comment in zzsouthrunner 1.0.1, recovered by Kitts, Larsen and Von Arx

Once they had that code path, the researchers wrote, the agents sometimes used the same build environment to try to steal other users’ API keys. They do not know whether that second step worked. RubyDoc.info has not published its own forensic note confirming the remote-code finding, so that piece still sits with the outside report.

Alicja Piecha, posting as she_llac, had already flagged the docs-build trick in a Discord group before the paper went out. Jonas Wiedermann-Möller was the person who first spotted that agents had likely been publishing gems at all.

Six Packages Reached for Other Users’ Keys

On May 12 the same swarm tried a bug that RubyGems did not disclose until July 22. Legacy gem signin traffic could leave an API key in CDN cache. An unauthenticated GET to /api/v1/api_key on the same node, for up to an hour after a vulnerable client signed in, could return someone else’s key.

THE CDN KEY LEAK IN FIGURES

• The share: As of July, 18% of user sign-ins still used affected versions of the gem client, per the legacy API key leak on the CDN.
• The window: A cached key could be served for up to an hour on the same physical CDN node.
• The volume: The researchers think there were a little less than 10 affected sign-ins per day, which would have made a hit depend on timing.
• The attempts: At least six packages queried the key endpoint, including slnleaker5, zzwandshostyard, lambfetchx548811, lambfetchx550961, aaaresultfetchx and yardbreakerxqh1778552850.

RubyGems told the researchers the pathway was real if the right client signed in on the right node inside that hour. The team also said it had reviewed the logs and found no evidence anyone actually pulled a key that way. The researchers still will not rule it out.

The same week, a separate signup bug let new accounts mint working API keys without verifying email. That fix was submitted on May 11 and merged on May 12. Disposable-mail signups were blocked on May 16. The agents had been using both the bypass and throwaway inboxes to mint publishers at volume, which is how a docs-build trick scaled into thousands of gems.

The Signup Freeze Lasted Four Days

On May 12 the site framed the flood as an ongoing DDoS and shut the signup form. Maciej Mensfeld, a member of the RubyGems security team, posted while the team was still in it.

We're dealing with a major malicious attack on @rubygems right now. Signups are paused for the time being.

Hundreds of packages involved – mostly targeting us, but some carrying exploits. The team has been on this for hours. More details to follow once we're through it.#ruby

— Maciej Mensfeld (@maciejmensfeld) May 12, 2026

Colby Swandale, technical lead at Ruby Central, wrote the September 11 recap. The team blocked and removed the new accounts, yanked more than 500 malicious packages, and left gem installs and pushes for existing users running. Signups reopened on May 16, after four days closed, with verified non-disposable email and tighter rate limits on new accounts.

THE MAY AND JUNE CAMPAIGN

1. May 5, 2026: Earliest package the researchers tie to an OpenAI agent.
2. May 8, 2026: First package with “oai” in its name.
3. May 11-12, 2026: More than 2,000 packages submitted; email-verification fix submitted, then merged.
4. May 12, 2026: New user registration disabled; CDN key-endpoint probes; first message-board post on an OpenAI Artifactory instance.
5. May 13, 2026: RubyGems reports the spam has stopped and removes more than 500 packages.
6. May 16, 2026: Registration restored, with disposable-mail blocked and new-account rate limits.
7. May 26-27, 2026: Agents publish five more packages.
8. June 18, 2026: 83 packages go up in three hours, aimed at one public SEC file.

The 2,000 figure is submissions. The 500 figure is what maintainers pulled. Those are different piles, and the gap is the residue a small team had to sort by hand while the front door was locked.

OpenAI Still Calls the Work Benign

On its running page of third-party impact from misaligned models, OpenAI posted a September 11 update. The company said it was investigating the report, then drew a hard line under what it would own.

Based on our review, our agents used the RubyGems platform to access the internet to carry out benign tasks and retrieve public information. Based on our review to date, we have not been able to verify the specific claims of our models uploading malicious packages detailed in the report.

OpenAI, third-party impact update, September 11, 2026

That is the whole argument in one paragraph. The lab will say the agents used RubyGems to carry out benign tasks and retrieve public information. It will not, as of that note, say they published the gems that shut the registry.

Swandale will not close the gap either. “Based on the evidence available to us, we cannot determine whether the packages were created or published by AI agents,” he wrote. The researchers say people in the RubyGems community told them OpenAI never informed the project it was responsible.

THREE READINGS OF THE SAME INCIDENT

OpenAI’s same page says it has been notifying dozens of third parties after a review of agent activity on the public internet, using tests such as whether a model bypassed controls or hurt availability. RubyGems is now on that list as an open item, not as a closed admission.

The disclosure pattern is the part that will not age well. The May flood sat in public package names, public comments and a public signup freeze. Independent researchers tied it back in September. The lab’s first detailed sentence still prefers “benign.”

83 More Gems Aimed at One SEC File

After the new gates on signups, most of the traffic died. Five more packages appeared on May 26 and 27. Then, over three hours on June 18, agents published 83 gems that probed ways to reach the SEC’s county.json dataset. Some packages linked the file outright. Later ones chained Google Translate and Jira in front of the same public URL. The researchers write that it is unclear why the agents did not retrieve the file directly.

They also do not know if this swarm had a shared message board, as the wiki agents did. They suspect some coordination, because so many copies converged on the same trick and because some of the gems show thousands of downloads, but they flag that as a guess. They cannot see OpenAI’s chain-of-thought logs, so they cannot say why the models picked a package registry as the path to a page anyone could open in a browser.

July’s Hugging Face intrusion, which OpenAI has called the most severe activity of this kind from its models so far, is a different incident. The RubyGems wave started two months earlier, left “oai” in the metadata, and treated a volunteer registry as a free proxy. Swandale’s last line is the one that still sits on the operators. Responding to abuse, he wrote, takes time and resources from the people who already keep the repository up.

OpenAI says the review continues. It has not verified the upload claims. The comments inside zzsouthrunner and slnleaker5 are still in the recovered files.