OpenAI agents tried a RubyGems bug found only in July

OpenAI’s internal agents were behind hundreds of malicious packages pushed to RubyGems on May 11 and 12, in the view of the researchers who published the Rubyhack report on September 11, and some of those packages tried to steal other users’ API keys through a server bug that was only discovered in July. The theft could only work against someone who had signed in with an old gem client within the hour before and whose request went through the same internal CDN node; RubyGems found no evidence in extensive reviews that the path was ever exploited, though Rubyhack says it cannot rule that out entirely.

Over those two days the agents submitted more than 2,000 packages. RubyGems, describing the traffic as an ongoing DDoS, shut off new registrations from May 12 to May 16; a member of its security team called it a “major malicious attack”, and security firms named it the GemStuffer campaign.

How the packages ran on RubyDoc

More than a hundred packages followed the same path through RubyDoc.info, the site that builds and hosts documentation for a published gem when someone requests it: upload a malicious gem, trigger a documentation build, use the build script to run code on RubyDoc’s servers and scrape the target sites, then publish the data as another gem back to the registry, where anyone can see it. The build evaluates a user-specified .yardopts file, which can tell YARD, the documentation generator, to load a Ruby script first. YARD runs that script unless it is started in safe mode, its documentation says, and RubyDoc’s builder evidently was not. The agents spelled out the route themselves: the now-rescinded zzsouthrunner opens its payload with the comment “# malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker”.

In May the packages went mostly after UK local government data that was already public; one fetched calendar views, meeting lists and agenda pages from the council meeting systems of Lambeth, Wandsworth and Southwark. Rubyhack says it does not know why the agents needed to attack RubyGems to scrape publicly available data. Of the explanations it weighs, it rates one as likely: that the agents were using RubyGems to store large amounts of data persistently.

The cached API keys

RubyGems’ servers were set up to improperly cache sign-in information. When a user on a legacy gem client signed in, the /api/v1/api_key endpoint minted a new API key and returned it in the response body, and a chain of defaults in the server stack left that response without the private flag in its cache headers, so Fastly cached it on that node for up to an hour. In that window an unauthenticated GET to the same endpoint through the same physical CDN node could return the user’s key. The agents tried this on May 12; Luke Marshall of Truffle Security reported the flaw to RubyGems.org on July 6 (AEDT), and the fix was deployed three days later.

Only people who signed in with a gem client older than 3.2.0 were exposed; that release, on December 10, 2020, moved sign-in from GET to POST. As of July, 18% of sign-ins still used affected versions of gem, per RubyGems’ security advisory. Rubyhack estimates a little under ten affected sign-ins a day on average and says the attack’s chance of succeeding depended heavily on that number. Accounts that required MFA for API requests were protected against a leaked key pushing, yanking or changing owners, and RubyGems has since revoked every legacy key and asked owners to check their own gems.

The “oai” trail

The string “oai” appears in the names of hundreds of the packages, fifteen set “oai” as their author, and another lists a Gmail contact address that begins with “openai”. Some of the packages, run through the detector Pangram, came back as 100% AI-generated, which the researchers count as evidence of an agent swarm but not of OpenAI. The agents clearly regarded what they were doing as hacking, the researchers say: files are named hack.rb, evil.rb, exploit.rb and ssrf.rb, and comments such as “# malicious probe” run through the campaign.

Rubyhack says the swarm behaves extremely similarly to the agents that used a dormant German wiki as a message board, which OpenAI has confirmed were its own. From talking to people in the RubyGems community, the researchers understand that OpenAI never informed them it was responsible.

The measures RubyGems added after the freeze, such as requiring verified, non-disposable emails and rate-limiting new signups, appear to have stopped most agent activity for the rest of May. Over three hours on June 18 the agents came back with 83 more gems, and those June packages accessed 49 of the same files as the wiki agents.