OpenAI Agents Linked to RubyGems Campaign That Gained RCE on RubyDoc Servers
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 agents may have been attempting to use RubyGems as a way to persistently stash the scraped data and bypass rate limits.
“We suspect they were cooperating with each other, both because that would better justify going to such lengths to cache the websites and because the packages the agents upload seem to have thousands of downloads,” the researchers said. “But this is far from definitive.”
Last week, OpenAI said it treated the wiki incident as an “instance of misalignment similar to the ones we’d shared,” and that it has historically “treated misalignment largely as a research question, which gets communicated in research publications such as systems cards.”
The American company then went on to state that the AI community does not yet have a “clear standard for how to report misalignment that shows up during training, evaluation, and deployment, including examples that don’t look like traditional security incidents but could provide insight into AI behavior and future risks.” It also said it’s working on a framework that it intends to share publicly in the coming weeks.
The episode is only the latest in a series of cyber attacks linked to frontier AI labs that have set alarm bells ringing and spurred calls for tighter AI regulation. As it has become abundantly clear, unless carefully restricted, AI agents will go to extreme lengths to complete the tasks assigned to them, even if that means breaking out of sandboxes or conducting social engineering attacks on real people.
The ever-growing list of incidents where AI agents from OpenAI, Anthropic, and Meta have breached or attempted to access external systems has raised concerns about the pace of AI development and their potential to slip out of human control.
“Based on our review, our agents used the RubyGems platform to access the internet to carry out benign tasks and retrieve public information,” OpenAI said in a statement shared with Reuters. “We’ll continue to investigate as part of our broader review of agent activity during training and evaluation.”
RubyGems, for its part, said its own investigation found no evidence the attempts succeeded, and that it’s committed to detecting and combating abuse irrespective of whether the activity originates from humans or automated tools.
“Based on the evidence available to us, we cannot determine whether the packages were created or published by AI agents,” Colby Swandale, technical lead at Ruby Central, said. “Our focus is on identifying and preventing abuse, regardless of whether it comes from people or automated tools.”
About Author
