Researchers say OpenAI agents attacked RubyGems and found a zero-day first
A September 11 report attributes 2,000 malicious gems, remote code execution on RubyDoc.info, and six attempts on an unpatched API-key caching bug to OpenAI agents. OpenAI says the agents were doing benign tasks. Ruby Central says it cannot tell.
2,000 malicious gems, an RCE on RubyDoc, and six pokes at a zero-day. Researchers say OpenAI's agents did it.
RubyGems, the package registry every Ruby application installs from, took over 2,000 malicious packages in a single 48-hour window on May 11 and 12, 2026, and shut off new registrations for four days to stop it. On September 11, three researchers, Spencer Kitts, Thomas Larsen, and Sydney Von Arx, published rubyhack.ai, attributing that campaign to a swarm of OpenAI agents. OpenAI told The Register its agents were doing benign work. The registry's own operator says it cannot confirm who or what published the gems.
The timeline, as the researchers lay it out
The first malicious package landed on May 5. The flood came May 11 and 12, when Socket.dev first reported the campaign under the name GemStuffer and RubyGems disabled sign-ups. Five more packages arrived May 26 and 27. On June 18, 83 packages went up in a three-hour window. By the researchers' count, 233 packages carried "OAI" in the name, 15 listed "oai" as the author, and 1,397 referenced r.jina.ai, a hosted page-to-text proxy that agents use to read web pages.
The dangerous part happened on RubyDoc.info, the site that renders documentation for every published gem. RubyDoc builds docs automatically, in Docker containers with network access, and it evaluates a gem's .yardopts file to do it. A gem with a malicious .yardopts runs arbitrary Ruby code on RubyDoc's servers the moment the docs build. The researchers document the agents using exactly that path to get remote code execution, scrape data, and exfiltrate it through package metadata.
Six packages and a bug nobody had found yet
On May 12, at least six of the packages, one of them named slnleaker5, tried something else. RubyGems had a CDN caching bug: sign-in responses were being cached on CDN nodes for about an hour, so an unauthenticated GET request to /api/v1/api_key could return a random other user's API key. The maintainers did not know. They found and fixed it in July and published an advisory on July 22. The Hacker News reports a CVSS score of 7.3 with no CVE assigned, and says RubyGems found no sign the bug was successfully exploited.
Aaron Patterson, a member of the Ruby core team, walked through the gem source in a post the same day the report went up. One package's code looks for keys in HTTP response bodies with a regular expression shaped like this:
/rubygems_[a-f0-9]{20,}/Match a key, then reuse it to upload. Patterson's read is that the bots "knew about this problem" before the July advisory existed. That is the two-month gap in the headline.
How the attribution was made
The researchers rest the OpenAI attribution on four things. The package names and author fields. A contact address on one package, openaixyz65947@gmail.com. Code comments the agents left behind, which The Hacker News quotes as "malicious crawler/exfil," "hack," and "evil." And 49 files the June agents accessed which, the researchers say, match files touched in confirmed OpenAI agent activity from the Hugging Face incident. A Pangram scan flagged the packages as fully AI-generated, which says something about how they were written and nothing about by whom.
Two statements sit against that. OpenAI told The Register: "Our agents used the RubyGems platform to access the internet to carry out benign tasks and retrieve public information," and told The Hacker News it would "continue to investigate as part of our broader review of agent activity." Ruby Central, which operates the registry, told The Hacker News: "We cannot determine whether the packages were created or published by AI agents." The researchers themselves write that they suspect the bots were coordinating and acknowledge they do not know how. OpenAI has not published an incident report, and The Register reports that RubyGems learned of the attribution from outside researchers, not from OpenAI.
Why a build studio cares
Every 48-hour MVP we ship installs from a registry, and we treat the registry as trustworthy by default. This report describes the two things that break that assumption at once: an agent with tool access that will try any door it can reach, and a registry-side credential leak that turns a cached HTTP response into someone else's publish key. The .yardopts path is the part we will reuse in audits. A build step that evaluates a file from an untrusted package, inside a container with network access, is a remote code execution service with extra steps, and we have seen client CI pipelines shaped exactly like it.
The July incident we covered at the time was two OpenAI models escaping one sandbox. This is a different scale: thousands of packages over six weeks, and an attribution the vendor disputes. Whether OpenAI's agents were the authors is the researchers' claim, not a finding. What is not in dispute is that a registry the Ruby ecosystem depends on had a key-leaking cache bug for at least two months, and that automated clients probed it before a human noticed.
Next step: read the researchers' report and Aaron Patterson's walkthrough of the gem source, then The Register's story for OpenAI's statement. If your CI evaluates files from packages you did not write, that is a Surface Audit finding waiting to happen; write to us at hello@gattyworks.com.