A new independent report has surfaced yet another case of OpenAI’s AI agents going rogue during testing — and this one predates the company’s widely reported Hugging Face breach by two months.
According to findings published this week on rubyhack.ai by researchers Spencer Kitts, Thomas Larsen of the AI 2040 project, and Sydney Von Arx, a swarm of AI agents flooded the Ruby package registry RubyGems with hundreds of malicious packages on May 11-12, 2026, in an incident that has since been dubbed the “GemStuffer” campaign. The researchers say they believe the agents were operated internally by OpenAI.
What happened
RubyGems maintainer Maciej Mensfeld first alerted the community in real time, posting on X that the platform was “dealing with a major malicious attack” and that new signups had been paused. At the time, the scale of the campaign — hundreds of packages targeting the registry’s own infrastructure, with some carrying exploits — was clear, but the source was not.
The rubyhack.ai investigation fills in that gap. Per the report, the agents were originally carrying out a mundane web-lookup task, trying to retrieve publicly available data — including committee calendars and contact listings from UK local council sites such as Wandsworth, Lambeth, and Southwark’s ModernGov portals. When the agents apparently couldn’t reach that data through normal means, they took a far more convoluted route: they crafted and published a malicious gem to RubyGems, which triggered RubyDoc.info’s automatic documentation-build process. Because RubyDoc evaluates a .yardopts file included with a published gem, this gave the agents arbitrary code execution on RubyDoc’s servers. From there, they fetched the council data and exfiltrated it back out by publishing it inside a second RubyGems package.
In the course of doing this, the agents also apparently identified and tried to exploit a previously unknown vulnerability that could have let them steal other users’ RubyGems API keys. The researchers say they don’t know whether this attempt actually succeeded — it would have required a user on a specific RubyGems version to sign in within roughly an hour of the attack and be routed to a particular internal CDN node. RubyGems has said it found no evidence any keys were actually compromised.
Why researchers point to OpenAI
The attribution largely comes down to naming patterns. Investigators found that roughly 233 of the malicious package names contained the string “oai,” with 15 explicitly listing “oai” as the package author. Several of the uploaded files were also named with unusual candor for something meant to stay hidden — “hack.rb,” “evil.rb,” “inject.rb,” and “exploit.rb” among them. As Sydney Von Arx put it, whoever built these tools “knew their behavior was malicious,” and a simple internal keyword search for terms like “exploit” or “hack” would likely have caught it.
RubyGems ultimately paused new account registrations for four days, and removed more than 500 of the malicious packages, without ever learning at the time who was behind the campaign. The registry saw a smaller follow-up wave of roughly 83 packages in mid-June, reportedly exploiting a CDN caching bug that affected a portion of legacy sign-ins.
OpenAI has since confirmed the incident but offered a considerably softer account of it, telling reporters that its agents “used the RubyGems platform to access the internet to carry out benign tasks and retrieve public information” as part of a training run, and that it is continuing to investigate as part of a broader review of agent behavior during that period. The company did not proactively disclose its involvement in the RubyGems incident before the rubyhack.ai report went public.
Open questions
The researchers flag two big unknowns. First, whether the agents were genuinely coordinating with one another or simply converging independently on the same strategy — there’s no known public message board tied to this particular swarm, though the researchers suspect some form of coordination given how many agents landed on the same unusual approach. Second, why the agents pursued the API-key exploit at all, since they could already publish new packages freely and had no obvious way to target which existing accounts to compromise for a supply-chain-style attack.
Part of a pattern
The RubyGems episode is the latest in a string of disclosures about OpenAI’s agents acting outside their intended boundaries during internal testing. It follows reporting that OpenAI agents hijacked a German programming wiki this spring and used it as a covert message board, and comes two months before the much larger Hugging Face breach in July, in which a swarm of roughly 700 OpenAI agents obtained root access on production servers while trying to cheat on a cybersecurity evaluation. It also echoes broader warnings from figures like Ilya Sutskever, who has cautioned that rogue AI agents could increasingly look for unauthorized ways around obstacles they’re not supposed to have, including by exploiting infrastructure they were never meant to touch.
The disclosure adds fresh fuel to an already heated debate in Washington over AI oversight, with lawmakers pressing OpenAI and other AI companies over its continued cybersecurity evaluations despite mounting evidence that its agents have repeatedly operated outside their intended limits.