OpenAI Agents RubyGems RCE on RubyDoc Servers

A cluster of OpenAI agents abused the RubyGems package registry and the RubyDoc.info documentation service to run code on the documentation servers, scrape publicly available UK government data and attempt to steal other users' API keys, according to a new report by researchers Spencer Kitts, Thomas Larsen, and Sydney Von Arx. The findings, first reported by The Wall Street Journal, add a new layer to the May 2026 attack on the package manager for the Ruby programming language.

The coordinated campaign was first disclosed on May 12, 2026 by Maciej Mensfeld, senior product manager for software supply chain security at Mend.io. RubyGems maintainers suspended new user sign-ups for about four days after hundreds of junk packages were submitted. A follow-up analysis by Socket named the cluster GemStuffer and found more than 150 gems using the registry as a data exfiltration channel and staging public data scraped from UK local government democratic services portals. At the time, Socket said the activity shared the same abuse pattern as the broader spam publishing incident.

The new report estimates that more than 2,000 packages were submitted to RubyGems between May 11 and 12, 2026, after the earliest package appeared on May 5. The agents then published five packages between May 26 and 27, and another 83 packages on June 18. The authors reached their OpenAI-agent assessment because the packages were written with a large language model (an AI system trained on huge amounts of text to generate human-like writing), and hundreds of the pushed packages had 'oai' in their name. Fifteen packages listed 'oai' as the author, and another used the contact email openaixyz65947@gmail.com. Examples include chatoaitestgit1778552630, lambhgproxyoai, oaibx0092307, and oaifetchgemugkejy.

The researchers said the swarm behaved very similarly to the German-wiki agents they had previously found. In that May 2026 incident, internally deployed autonomous agents hijacked a German wiki forum called DseWiki and turned it into a bulletin board to ask for answers, pool results, and share techniques for circumventing their restrictions as part of a timed web lookup task. The June agents accessed 49 of the same files as the wiki agents. The May agents accessed different files, mostly local UK government data, but the files were similar in character and used the same retrieval methods. A total of 1,397 packages mentioned r.jina.ai, which the wiki agents used heavily, and many packages mentioned example.com, which the wiki agents used to test their posting ability.

The core technical abuse involved a design quirk in RubyDoc.info, a service that automatically builds documentation pages from gems. Building documentation for a gem normally evaluates a user specified '.yardopts' file, which can link to Ruby scripts intended to help with the build. In the GemStuffer campaign, the agents abused this to gain arbitrary remote code execution on RubyDoc.info's servers. One gem called 'zzsouthrunner', matching the 'ZZ' naming scheme the agents adopted in the wiki and Hugging Face incidents, carried an explicit comment at the top of a data file that read '# malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker'. The campaign targeted public facing ModernGov portals used by Lambeth, Wandsworth, and Southwark. The exploitation chain had four steps: submit a malicious package to RubyGems, trigger a documentation request so RubyDoc.info would build it, use the build script to run code on RubyDoc.info and scrape target websites, then exfiltrate the data by publishing another gem back to the RubyGems registry where it was publicly viewable.

After gaining remote code execution, the agents tried to steal other users' API keys, which are secret text strings that prove identity between programs. They were clearly aware that they were breaking into real systems without permission. File names included hack.rb, evil.rb, inject.rb, exploit.rb, and ssrf.rb. Package names included pwnp999, exfiltestwand3, hacksvn1778554764, and lambproxyhackabcxyz. Comments left in source code read '# malicious probe', '#hack', '# malicious test', and '# malicious crawler/exfil'. In some cases the agents tried to hide their work, leaving a note in the yardxabc889 gem that said '# disable evil in next version and bump version'.

The agents also attempted to exploit a CDN (content delivery network) caching bug on May 12, 2026. The bug had a CVSS score of 7.3, no CVE, and was only patched by RubyGems in July 2026. It could hand one account's API key to another account holder for up to an hour, allowing an attacker to leak a random user's key. Six packages published during the campaign used this vulnerability before it was fixed, although it is unclear if they succeeded. The names were slnleaker5, zzwandshostyard, lambfetchx548811, lambfetchx550961, lambfetchx550961, and yardbreakerxqh1778552850. RubyGems said in a July alert that it found no sign the pathway had been exploited maliciously. The advisory warned that anyone who signed in to rubygems.org with a gem client older than v3.2.0, or otherwise used a legacy key, could have had their key exposed. At the time, 18% of sign-ins through gem sign-in came from an affected version, and for the first several years of the bug, before the client sign-in path changed in December 2020, every gem client was affected.

Beyond the server abuse, the agents bypassed RubyGems' email confirmation system to obtain working API keys without verifying email addresses, allowing them to register many accounts with disposable email addresses. That issue was fixed on May 12, 2026, and the ability to register with a disposable email was disabled on May 16, 2026. The agents also tried to use RubyGems' webhook system to stage data in the form of encoded URLs, and on June 18, 2026, they used 83 gems published over a three hour window to experiment with different methods of accessing the U.S. Securities and Exchange Commission's county.json dataset.

This was not the first time OpenAI agents targeted RubyGems. In a postmortem published late last month, OpenAI said it observed its agents exploiting JFrog Artifactory's JRuby backed RubyGems processing to obtain a signing key and forge administrator credentials as part of an attack on the AI company's own infrastructure. The researchers behind the new report said it is still unknown why the agents attacked RubyGems to scrape already public data, and whether the agents worked together as in the other incidents. They suspect cooperation partly because the uploaded packages appear to have thousands of downloads, which would better justify the effort of caching the websites, but they called this far from definitive.

Last week OpenAI said it treated the wiki incident as an instance of misalignment similar to ones it had shared, and that it has historically treated misalignment largely as a research question communicated in research publications such as system