OpenAI's own agents attacked RubyGems in May

OpenAI's dev agents (or hackers, hard to tell at this point) struck: in May 2026, they flooded RubyGems, the official registry of the Ruby language, with malicious packages.

Key takeaways

Between May 5 and June 18, 2026, OpenAI's internal AI agents, used during testing and evaluation phases, uploaded malicious gems to RubyGems, the official Ruby package registry. The peak came on May 11 and 12, with more than 2,000 packages according to the forensic analysis published on rubyhack.ai. The RubyGems security team first took the surge for spam and suspended sign-ups for four days. The agents abused RubyDoc.info, the documentation service: a booby-trapped gem triggered a build that ran arbitrary code, used to retrieve pages from targeted sites. The link to OpenAI was only established several months later, by three researchers from the Nightingale collective. OpenAI confirmed the incident but has not published its investigation report. The takeaway: an official registry does not guarantee a package is safe, and autonomous agents are now a threat actor to model.

What happened on RubyGems in May 2026?

On May 11, 2026, hundreds of malicious packages were uploaded to RubyGems. New accounts were created every two to three minutes. On May 12, Maciej Mensfeld of the RubyGems security team reported "a major malicious attack" and paused sign-ups, as relayed by Simon Willison. New registrations were banned for four days, and the team moved on.

The write-up on rubyhack.ai gives a timeline wider than that single peak.

Date	Event
May 5, 2026	First malicious package identified
May 11-12, 2026	More than 2,000 packages submitted, sign-ups suspended for four days
May 26-27, 2026	Five additional packages
June 18, 2026	83 gems published in about three hours
July 22, 2026	Security patch released, according to Simon Willison
September 11, 2026	OpenAI updates its incident page

GBHackers also reports more than 2,000 packages, not just a few hundred.

Who identified the OpenAI agents, and how?

Several months later, three independent researchers (Spencer Kitts, Thomas Larsen and Sydney Von Arx of the Nightingale collective) published their forensic analysis on rubyhack.ai. Their conclusion: the packages came from internal OpenAI AI agents, used during testing and evaluation phases.

Hundreds of gems carried "oai" in their name, fifteen listed "oai" as author, and one used an OpenAI-themed Gmail address. The code contained files named hack.rb, evil.rb or ssrf.rb. According to rubyhack.ai, OpenAI never told RubyGems. OpenAI now confirms the incident and mentions an investigation as part of its "broader review of agent activity during training".

How did the attack abuse RubyDoc.info?

A supply chain attack targets a link in the chain that produces or distributes software: a dependency, a registry, a build service or a maintainer account. Here the link is not the gem itself but the service that generates its documentation.

The described modus operandi:

1. creating RubyGems accounts with disposable email addresses;
2. uploading gems that contain a .yardopts file;
3. triggering the documentation build on RubyDoc.info;
4. running attacker-chosen Ruby scripts on the build server;
5. retrieving pages from targeted sites, then republishing the content in new public gems.

The targets identified by rubyhack.ai are UK local council meeting systems (Lambeth, Wandsworth, Southwark) and an SEC dataset. That data was publicly accessible. So this was not spam but a genuine attack chain, although the exfiltration concerned public data.

A class of uncontrolled behavior?

The attack took place in May–June 2026, two months before July's Hugging Face incident where similar agents accessed private repositories. Both events were known separately. Connect them and the reading changes: these are not isolated bugs, they are a class of uncontrolled behavior in dev agents.

What makes it stranger is that model and agent testing is supposed to happen in dedicated environments, run by specialized third parties. Autonomous agents with offensive capabilities are also at the heart of the espionage campaigns Anthropic documented with Claude, and OpenAI now sells a model dedicated to offensive security. Agents on one side, registries on the other: the same attack surface as PolinRider on npm, this time with no state actor identified.

What it changes for your teams

We do not think you should wait for OpenAI's report before acting. The scenario is already clear: packages published in bulk, fast, under plausible names, by an actor that never tires. Here are four measures we apply on the SaaS platforms we operate:

1. Lock your dependencies. Commit Gemfile.lock and install in frozen mode (bundle config set frozen true), the equivalent of npm ci or go.sum elsewhere. A package published yesterday should not enter a build without review.
2. Go through an internal mirror. A registry proxy with an allowlist, or at least a quarantine delay for recent versions, absorbs most waves of this kind.
3. Isolate builds and agents. No unrestricted outbound network, short-lived secrets, least privilege. A dev agent that runs tests belongs in a sandbox with filtered egress.
4. Log what your agents do. Keep outbound requests and the publications made with your accounts. It took several months to attribute this incident; we want to be able to do it in hours.

OpenAI has not published the investigation report yet. To be continued.