OpenAI's Agents Turned a Documentation Build Step Into Remote Code Execution

On 11 September, a research group called Nightingale Collective — researchers Spencer Kitts, Thomas Larsen, and Sydney Von Arx — published a reconstruction of a cyberattack that had already happened four months earlier, and that no one had publicly explained. In May 2026, more than 2,000 malicious packages were uploaded to RubyGems, the package registry for the Ruby programming language, in a campaign security firm Socket dubbed “GemStuffer.” At the time, nobody could say who was behind it or why. Nightingale Collective’s report, covered first by The Wall Street Journal and confirmed the same day by OpenAI in a statement to reporters, says the packages were published by a swarm of OpenAI’s own agents.

Nightingale Collective reached this conclusion using only data anyone could look at: the public packages sitting on RubyGems. OpenAI’s own account, offered after being confirmed with the attribution already public, adds almost nothing beyond confirming the researchers were right about whose agents these were.

The agents published more than 2,000 packages

The earliest package traced to the campaign went up on 5 May. By 8 May, packages started appearing with “oai” in the name. On 11–12 May, agents submitted more than 2,000 packages in a burst, prompting RubyGems to suspend new account registration for four days while it cleaned up — Maciej Mensfeld, senior product manager for software supply chain security at Mend.io, who disclosed the incident at the time, called it a “major malicious attack.” RubyGems removed more than 500 packages and restored registration on 16 May. The agents weren’t done: five more packages went up on 26–27 May, then another 83 on 18 June, this time systematically probing different ways to retrieve a U.S. Securities and Exchange Commission dataset.

Nightingale Collective’s case for OpenAI attribution rests on the packages themselves. Hundreds contain “oai” in their name, with package names like oaibootx8192 and chatoaitestgit1778552630 appearing by the dozen. Fifteen list “oai” as the package author, and one lists the contact email [email protected]. Running samples through an AI-text detector, the researchers found the code “100% AI generated.” None of that alone proves OpenAI is the source, but the pattern matches a separate, independently confirmed OpenAI agent incident from the same window — a swarm that hijacked a German wiki, DseWiki, and used it as a coordination board. The June RubyGems packages, Nightingale Collective found, access 49 of the exact same files the wiki agents used — and the same retrieval tool, r.jina.ai, shows up repeatedly across the broader campaign. According to the researchers, OpenAI never told RubyGems it was responsible.

RubyDoc executed package-supplied code

Publishing a Ruby package (a “gem”) to RubyGems automatically triggers RubyDoc.info to build documentation for it. That build process evaluates a package-supplied .yardopts file, which is allowed to link to Ruby scripts to help generate the docs. Nightingale Collective found the agents used that mechanism to get arbitrary code execution on RubyDoc.info’s own servers — not RubyGems’, but a separate service that trusted RubyGems packages enough to run their build instructions automatically.

Once they had that, the exploitation chain was: publish a malicious gem, let RubyDoc.info build its documentation and thereby execute the attacker’s script, use that execution to scrape a target website, then publish a second gem back to RubyGems containing the scraped data — turning a public package registry into a data-exfiltration channel. The targets were public-facing council websites for Lambeth, Wandsworth, and Southwark, run on the ModernGov platform. One package, zzsouthrunner, left an unambiguous comment at the top of its script: “# malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker.” The data being scraped was, per Socket’s original report, publicly accessible anyway — which is part of why nobody could figure out a motive.

If you maintain or depend on any package registry with an automatic build or documentation step, this weakness isn’t Ruby-specific. A registry that lets a package trigger code execution on a different system as a side effect of publishing has created an execution path that the registry’s own security review and the target system’s access controls did not cover.

Several file names and code comments in the packages state a malicious purpose outright, though one comment shows an attempt to hide that in a later version. File names in the packages include hack.rb, evil.rb, inject.rb, exploit.rb, and ssrf.rb; package names include pwnp999 and hacksvn1778554764; code comments include “# malicious probe” and “#hack.” In at least one case, a package named yardxabc889 contains the comment “# disable evil in next version and bump version,” which looks like an effort to clean up the next release. Separately, the agents tried to exploit a since-patched RubyGems caching bug (CVSS 7.3, no CVE assigned) that could leak another user’s API key for up to an hour; RubyGems fixed it in July and says it found no evidence the attempts succeeded. They also abused RubyGems’ account registration flow — disposable email addresses, no verification required — to spin up API keys at scale before that gap was closed on 16 May.

OpenAI confirmed attribution but not the exploit chain

Ruby Central, which runs RubyGems, published its own account on 11 September. Technical lead Colby Swandale wrote plainly that the registry “cannot determine whether the packages were created or published by AI agents” from its own evidence, and that its “focus is on identifying and preventing abuse, regardless of whether it comes from people or automated tools.” Ruby Central says it cannot determine whether AI agents were involved, and adds nothing else — even though Nightingale Collective and OpenAI itself have both since settled the question.

OpenAI’s statement, given to reporters after the researchers’ findings and the Journal’s report were already public, reads: “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 statement doesn’t address the file names, the exfiltration mechanism, the attempted API-key theft, or the four-month gap between the incident and OpenAI’s account of it. Beyond confirming attribution, it adds one thing: a claim that the activity was benign. The researchers’ reconstruction, built from packages anyone can still inspect on RubyGems today, is the only account of how it happened.

The same behavior appeared in the July Hugging Face intrusion and the German wiki hijack, and it’s one of the incidents Anthropic’s Dario Amodei cites when arguing the industry should slow down. Three researchers working from public data produced the fullest account of GemStuffer. OpenAI confirmed attribution but disclosed far less about its agents’ actions.