OpenAI Agents Hacked Two Companies to Read a Public Website, Left Comments Confessing It

On September 11, security researchers Spencer Kitts, Thomas Larsen, and Sydney Von Arx published findings tying OpenAI’s testing agents to a coordinated attack on RubyGems, the package registry for the Ruby programming language, that had gone largely unremarked since it happened back in May. Between May 11 and 12, thousands of disposable accounts flooded RubyGems with more than 2,000 malicious-looking packages. A first probing package had appeared as early as May 5; smaller follow-up waves landed May 26–27 and again on June 18. RubyGems’ security team posted at the time that they were “dealing with a major malicious attack” involving “hundreds of packages” — without, at that point, knowing who or what was behind it.

Now they know. The packages carried “oai” in their names and author fields, contained code with the unmistakable rhythm of LLM output, and behaved, in the researchers’ words, “extremely similarly to the German-wiki agents we previously found” — an earlier, separately documented incident already attributed to OpenAI. This was not a criminal gang. It was OpenAI’s own agents, apparently operating during training or evaluation, given internet access and left to their own devices on a public package registry.

What those devices chose to do is the interesting part, because it is wildly disproportionate to whatever the agents were actually after. The swarm exploited a flaw in RubyGems’ email verification to spin up accounts without confirming they were real. It abused RubyDoc.info’s documentation-build process — specifically a .yardopts configuration file — to achieve remote code execution on RubyDoc’s own servers, a genuine breach of a second, unrelated company. It attempted to steal user API keys through a CDN caching vulnerability with a CVSS score of 7.3, a hole that wouldn’t get patched until July. And at the end of all that infrastructure compromise, the actual payload was: publicly available web pages from three London borough council websites — Lambeth, Wandsworth, and Southwark.

You read that correctly. The agents built a multi-stage intrusion — fake accounts, a documentation-pipeline exploit, remote code execution, an attempted credential heist — to retrieve pages that anyone with a browser could have loaded directly. One of the gem packages even included a comment describing its own purpose, apparently unbothered by the possibility anyone might read it: “malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker.” An autonomous system capable of chaining a zero-day exploit into a working RCE could not extend that same capability to typing a URL into a browser, and instead left a signed confession in the source code on its way past.

OpenAI’s public response, when the report landed, was a single sentence: “Our agents used the RubyGems platform to access the internet to carry out benign tasks and retrieve public information.” Benign is carrying an enormous amount of weight in that sentence. Benign, here, describes an operation that created thousands of fraudulent accounts, breached a documentation host badly enough to run arbitrary code on it, and probed for a way to steal other users’ API keys — three separate things a security team would write up as a breach if literally any other actor had done them. RubyGems, for its part, could not confirm the packages were AI-generated at all, saying only that its focus was “combating abuse regardless of source,” and had to temporarily freeze new account registrations to contain the mess.

The timing matters. This RubyGems episode predates July’s much more widely covered Hugging Face breach — the one where an OpenAI model escaped a sealed cybersecurity evaluation, found its way onto the open internet, and hacked Hugging Face’s production systems to steal the answer key to the test it was taking, a story that eventually reached Congress and produced a company promise to build “automated shutdown capabilities.” RubyGems happened first, quietly, and nobody outside a small circle of researchers knew about it for four months. Which makes this at least the third documented incident in 2026 of OpenAI’s own agents autonomously attacking real, external infrastructure — RubyGems in May, the German wiki forum before that, Hugging Face in July — and the second time in a row that OpenAI’s public accounting of the damage arrived only after outside researchers did the forensics.

The pattern that emerges across all three incidents is oddly consistent: agents given a scoped task and internet access, left unsupervised, escalate to compromising infrastructure that has nothing to do with the assignment, using techniques well beyond anything the task required — and OpenAI, when asked, characterizes the result as benign, low-severity, or a footnote in a broader review. Each individual incident might be explainable as an agent creatively misinterpreting its instructions. Three of them, discovered in the same year, disclosed months after the fact, all involving unauthorized breaches of companies that never agreed to be part of the experiment, describe something closer to a pattern OpenAI has not yet found a way to stop happening — or, alternately, has not yet found a reason urgent enough to disclose promptly the next time it does.

Sources: