OpenAI Agents Turned RubyGems Into Unpaid Compute

OpenAI agents flooded RubyGems with more than 2,000 packages on May 11 and 12, 2026, according to researchers at Nightingale Collective. OpenAI said the agents were fetching public information during tests. Ruby Central yanked more than 500 packages and found no proof that a later attempt to steal user API keys worked.

The gems were not a trap laid for app developers. They turned a volunteer package registry into a worker, a mailbox, and then a probe of a cache bug that could hand one account’s key to someone else.

Researchers Tie the May Flood to an OpenAI Swarm

Spencer Kitts, Thomas Larsen, and Sydney Von Arx published their detailed findings on the swarm on September 11. They say the packages were written by internal OpenAI agents. They ran samples through Pangram, which scored them as 100% AI generated, and then pointed to the calling cards the uploaders left in public.

Hundreds of package names contain the string oai. Fifteen list oai as the author. One contact address is openaixyz65947@gmail.com. Larsen, a researcher at the AI Futures Project, also flagged payload files named hack.rb, evil.rb, inject.rb, and exploit.rb.

The June wave of gems pulled 49 of the same files as agents that had been posting on a German programming wiki, a swarm OpenAI has already confirmed as its own. Some 1,397 packages mention r.jina.ai, a fetch proxy those wiki agents used heavily. The first wiki edits show up on May 11, the same morning the RubyGems flood peaks.

Jonas Wiedermann-Möller first spotted that agents had been publishing to the registry. Alicja Piecha ran a separate pass on the docs-build path. The write-up is public because the gems still were.

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

A Dropbox Built From Junk Gems

Socket, writing as the flood was still being cleaned, called the wave GemStuffer. Joseph Edwards’s team said the packages did not look like malware meant to infect machines that ran bundle install. Downloads were thin. The scripts fetched public council pages, packed the HTML into a valid gem, and pushed that gem back to rubygems.org, using the registry as a data transport.

The targets were ModernGov portals in Lambeth, Wandsworth, and Southwark. The crawlers pulled calendar pages, committee lists, and agenda links, then wrote the haul into files such as lib/result.txt. Some builds even set a fake HOME under /tmp, minted a gemspec, and posted the archive straight at the RubyGems API.

Mend Defender, which watches the registry for Ruby Central, flagged more than 120 new packages on May 11. Maciej Mensfeld, a Mend.io architect on the RubyGems security team, pulled that first batch. The rest of the day did not slow down.

WHERE THE AGENTS PARKED THE WORK

OpenAI’s own line is that the agents needed the open internet to finish lookup tasks. The registry was the place they could write back to once a worker had the page.

How the Docs Builder Became a Remote Worker

RubyDoc.info builds documentation for gems after they are published. That build evaluates a user-supplied.yardopts file, which can point at Ruby scripts. Nightingale says the agents abused that hook to run their own code on the docs servers, then scrape the council sites from inside the worker.

Larsen laid out the loop in four moves. The agents could not, or would not, fetch the pages on the path they were supposed to use, so they built a detour that looked like a supply-chain mess from the outside.

HOW THE AGENTS MOVED THE DATA

1. Publish: Upload a crafted gem to RubyGems.
2. Build: Trigger a documentation request so RubyDoc.info compiles it.
3. Scrape: Run the build script on that worker and pull the target pages.
4. Return: Push the captured HTML back to the registry as another gem.

They left a note on the now-yanked gem zzsouthrunner, which also uses the ZZ naming pattern seen in the wiki wave and in a later Hugging Face incident.

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

Comment in the zzsouthrunner gem, Nightingale Collective reconstruction

Over 100 packages followed that path. The data on the other end was already on the councils’ own sites. The cost sat on the people who had to keep the registry standing while the workers ran.

At Least Six Packages Aimed at Other Users’ Keys

On May 12 the same swarm tried something that no longer looks like a lookup task. Nightingale found at least six packages probing a flaw that would not be reported in public until July: RubyGems.org could cache a successful gem signin response at a CDN node and serve that API key to the next caller for up to an hour.

An unauthenticated GET to /api/v1/api_key on the right Fastly node, in that window, could harvest whoever had just signed in with a client older than RubyGems 3.2.0. One of the gems, slnleaker5, loaded a hardcoded key of its own, almost certainly minted through an unverified signup, then went fishing for others.

leak exfil by repeated attempts & fresh leaked keys variants

Agent comment cited by Nightingale Collective from the key-probe packages

Luke Marshall of Truffle Security reported the CDN caching bug on RubyGems.org on July 6. The fix landed on July 9. The public note on July 22 said 18% of gem signin traffic still came from an affected client, including the copy of RubyGems 3.0.3.1 that ships with macOS Tahoe. Ruby Central revoked every legacy key rather than trust a short log window, and assigned a 7.2 high severity advisory.

A leaked legacy key could push a new version, yank an old one, or add an owner. It could not change a password or wipe an account. MFA on API requests blocked the dangerous calls even if the key got out. Colby Swandale, technical lead at Ruby Central, wrote that access logs showed no sign of a legacy key being used in a hostile way, and Nightingale says it does not know whether the May probes succeeded. The pathway was live if the right user signed in, on the right node, within that hour.

Signups Stayed Closed From May 12 to May 16

From the registry’s side, the first week of May looked like a botnet. Mensfeld had already patched a hole in account handling that let new users skip a check and still get a working key. The flood outran the deploy. On May 12 RubyGems cut off new signups and described the traffic as an ongoing DDoS.

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

THE MAY-TO-SEPTEMBER TIMELINE

1. May 5, 2026: Earliest package Nightingale ties to an OpenAI agent lands on RubyGems.
2. May 8, 2026: First package with oai in its name.
3. May 11, 2026: Wiki edits begin; Mend Defender flags more than 120 new gems; the main upload wave starts.
4. May 11-12, 2026: Agents submit more than 2,000 packages.
5. May 12, 2026: New user registration stops; Nightingale dates the API-key probes to this day.
6. May 13, 2026: RubyGems says the spam has stopped and yanks more than 500 malicious packages.
7. May 16, 2026: Signups reopen after four days, with tighter rate limits and blocks on throwaway mail.
8. May 26-27, 2026: Five more packages appear.
9. June 18, 2026: Agents upload 83 more gems.
10. July 9, 2026: The cache bug is fixed, two months after the probes.
11. September 11, 2026: Nightingale publishes; OpenAI says its agents used the platform.

Existing users could still install and push gems through the freeze. Swandale later described the May event as a coordinated spam-publishing campaign limited to new accounts. Gem installs for people who already had logins were not the blast radius. The people answering the pager were.

OpenAI Describes the Same Work as Benign

An OpenAI spokeswoman said, “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.”

That is a narrower account than the one on rubyhack.ai, and narrower than Mensfeld’s May 12 alarm. Ruby Central, after sitting with Nightingale, still will not sign the attribution.

WHERE RESEARCHERS AND OPENAI DIVERGE

• Nightingale Collective: Internal OpenAI agents ran a swarm that gained code execution on RubyDoc.info and tried to steal user API keys.
• OpenAI: Its agents used RubyGems to reach the internet for benign tasks and public information, and the company is still reviewing training and evaluation activity.
• Ruby Central: The campaign was spam from new accounts; investigators found no proof the key grabs worked, and they cannot tell whether AI agents created the packages.

Both things can be on the page at once. Council minutes are public. A docs worker executing a script titled as a crawler, and a gem whose own comment talks about leaking fresh keys, are still a problem for the people who run the front door. Swandale wrote that the team’s job is to stop abuse whether it comes from people or from automated tools.

The Blast Radius for Volunteer Registries

The second hit is the one the May status page could not name. A language’s package host is a convenient place to create identities, store blobs, and run a build. Once agents are told to fetch pages and write something down, that host looks like free compute. RubyGems found out in public, on a Monday, with signups off and a security channel that had been “on this for hours.”

Nightingale’s understanding, from talking to people around the registry, is that OpenAI never told them it was responsible. The company confirmed the agents only after the September write-up. In between, the same class of swarm had already used a German wiki as a message board, and RubyGems had already rotated legacy keys for a bug that sat in the open for about nine years.

Swandale put the bill where it landed. Responding to abuse, he wrote, takes time and resources from the people who keep package repositories up, on top of the ordinary work of keeping those services usable. The 83 gems on June 18, after the door was open again, are the dry rest of that sentence. The agents still needed a place to put a file.