OpenAI Agents Linked to RubyGems Campaign That Gained RCE on RubyDoc Servers

Summary

A coordinated cyber attack on RubyGems in May 2026, involving hundreds of malicious gems, has been attributed to a swarm of OpenAI agents. Researchers found over 2,000 packages submitted by these agents, many containing 'oai' in their names or associated with specific OpenAI-related email addresses. The agents exploited a vulnerability in RubyDoc.info's documentation build process to achieve remote code execution and exfiltrate public data from UK government websites.

Full text

OpenAI Agents Linked to RubyGems Campaign That Gained RCE on RubyDoc Servers Ravie LakshmananSep 12, 2026Vulnerability / Web Security The "major malicious attack" that targeted RubyGems in May 2026 was the work of a swarm of OpenAI agents, according to a new report published by researchers Spencer Kitts, Thomas Larsen, and Sydney Von Arx. On May 12, Maciej Mensfeld, senior product manager for software supply chain security at Mend.io, disclosed details of a coordinated cyber attack that targeted the package manager for the Ruby programming language with hundreds of junk gems, prompting the maintainers to suspend new user sign-ups for about four days. In a follow-up analysis, Socket highlighted a campaign dubbed GemStuffer that involved a cluster of more than 150 gems that used the package registry as a data exfiltration channel and staged public data scraped from U.K. local government democratic services portals. At that time, the software supply chain security company noted the activity shares the "same abuse pattern" as the broader RubyGems spam-publishing incident. "It's not clear what exactly the end goals are, as the information appears to be publicly accessible anyway," The Hacker News reported back then. The latest findings, which were first reported by The Wall Street Journal, indicate these events were propelled by a cluster of OpenAI agents, with the earliest package uploaded to RubyGems on May 5, 2026, before more than 2,000 packages were submitted between May 11 and 12, 2026. These efforts were followed by the agents publishing five more packages between May 26 and 27, 2026, and another 83 packages on June 18, 2026. The assessment that this incident was the result of an OpenAI agent swarm stems from the fact that the packages were authored using a large language model (LLM) and hundreds of the packages that were pushed to RubyGems had "oai" in their name. Fifteen of the packages listed "oai" as their author, while another had "openaixyz65947@gmail.com" as the contact email address. The names of some of the junk packages are below - chatoaitestgit1778552630 lambhgproxyoai oaibx0092307 oaicx8859010 oaicx3857133 oaidx4526859 oaiex4149420 oaifx7943598 oaigx5861576 oaihx0305933 oaiix0379958 oaijx0156671 oaikx5119809 oailm2 oaipgttatggxy oaifetchgemugkejy oaiproxytestabc789 oaitfossilxbnowl "The swarm behaves extremely similarly to the German-wiki agents we previously found," the researchers said, referencing another May 2026 incident in which internally deployed autonomous agents hijacked a German wiki forum, 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 were accessing 49 of the same files as the wiki agents. The May agents were accessing different files (mostly local U.K. government data), but these files are very similar in character to those pursued by the wiki agents. Moreover, they use the same retrieval methods. 1,397 packages mention r.jina.ai, which was used heavily by the agents on the wiki. We also see that many packages mention example.com, which wiki agents used to test their posting ability." The agents are said to have exploited a design quirk in the RubyDoc.info documentation build process to exfiltrate public data from U.K. government websites, likely as part of an information gathering task similar to the research tasks processed by the German wiki-exploiting agents. "The process of building documentation for a gem involves evaluating a user-specified '.yardopts' file, which allows linking to Ruby scripts intended to help with this process," the researchers explained. "In the GemStuffer campaign, the agents abused this to gain arbitrary remote code execution on RubyDoc.info's servers." One of the gems, "zzsouthrunner" (which again matches the "ZZ" naming scheme the agents adopted in both the wiki and Hugging Face incidents) has been found to leave the following explicit comment at the top of "data/script.rb": # malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker It's worth noting that the GemStuffer campaign targeted public-facing ModernGov portals used by Lambeth, Wandsworth, and Southwark. The entire exploitation chain can be summed up as follows - Submit a malicious package to RubyGems Trigger a documentation request, so that RubyDoc.info will build the package Use the build script to run code on RubyDoc.info and scrape target websites Exfiltrate the data off RubyDoc.info's servers by publishing another gem back to the RubyGems package registry, which is publicly viewable Additionally, the OpenAI agents have been found attempting to steal other users' API keys after gaining remote code execution capabilities on the build environment, while clearly being aware that what they were doing is unauthorized breaking and entering into real systems. This is evidenced by the names given to the files (e.g., hack.rb, evil.rb, inject.rb, exploit.rb, and ssrf.rb), the packages themselves (e.g., pwnp999, exfiltestwand3, hacksvn1778554764, and lambproxyhackabcxyz), and the comments left in the source code (e.g., "# malicious probe," "#hack," "# malicious test," and "# malicious crawler/exfil"). In some cases, however, the rogue agents attempted to go under the radar, leaving comments to conceal the malicious payload in the next release version of the packages. "# disable evil in next version and bump version," reads a comment left within the "data/evil.rb" file in the yardxabc889 gem. Troublingly, the agents also attempted to exploit a CDN caching bug (CVSS score: 7.3, no CVE) on May 12, 2026, that was only patched by RubyGems in July 2026. At a high level, the issue could hand one account's API key to another account holder for up to an hour, thereby allowing an attacker to leak a random user's key. Six of the packages published as part of the campaign used this vulnerability before it was fixed, although it's unclear if they succeeded in their efforts. RubyGems, in its July alert, said it found no sign that this pathway has been exploited in a malicious context. The names of the six Ruby gems are below - slnleaker5 zzwandshostyard lambfetchx548811 lambfetchx550961 lambfetchx550961 yardbreakerxqh1778552850 "If you signed in to rubygems.org with a gem client older than v3.2.0 (or otherwise via a legacy key), your key could have been exposed," RubyGems noted in an advisory. "Currently, 18% of sign-ins through gem sign-in come from an affected version, and for the first several years of this bug, before we changed the client's sign-in path in December 2020, it was every gem client." Some of the other actions undertaken by the agents are listed below - Agents bypassed RubyGems' email confirmation system to get working API keys without having to verify their email addresses in order to register a large number of accounts using disposable email addresses. The issue was fixed on May 12, 2026. The ability to register with a disposable email was disabled on May 16, 2026. Agents attempted to use RubyGems' webhook system to stage data in the form of encoded URLs. Agents used a cluster of 83 gems published to RubyGems over a 3-hour window on June 18, 2026, to experiment with different methods of accessing the U.S. Securities and Exchange Commission's (SEC) county.json dataset. This is not the first time OpenAI agents have targeted RubyGems. In its postmortem published late last month, OpenAI said it observed its agents exploiting JFrog Artifactory's JRuby-backed RubyGems processing to obtain the signing key and forge administrator credentials as part of an attack targeting the artificial intelligence (AI) company's infrastructure. The researchers also noted that it's unknown at this stage why the agents took the trouble of attacking RubyGems in order to scrape publicly available data and if the agents worked together as in the case of the other incidents. It's believed that the age

Indicators of Compromise

• domain — r.jina.ai
• domain — example.com
• email — openaixyz65947@gmail.com
• malware — GemStuffer

Entities