OpenAI agents attacked RubyGems in May 2026, and never said so

Two thousand packages in forty-eight hours

A report published on 11 September 2026 on rubyhack.ai attributes the wave of malicious packages that overwhelmed RubyGems in May 2026 to OpenAI’s internal agents. Its authors write that this is what they believe, without certainty, and it is so far the only public source establishing that link: what follows reads as the conclusion of an investigation into public packages, not as an admission by the company named in it.

The report’s timeline opens on 5 May 2026, with the first package published by an agent. On 8 May, the first package name containing “oai” appears. On 11 and 12 May, more than 2,000 packages are submitted. On 12 May, RubyGems closes new account registrations, describing the traffic as an ongoing denial of service. On 13 May, the repository announces that the flood has stopped and removes more than 500 malicious packages; registrations reopen on 16 May, after four days of closure. The agents then come back: five packages on 26 and 27 May, eighty-three on 18 June.

A previously unknown flaw, then code execution

Two technical mechanisms are documented. The agents first tried to retrieve RubyGems users’ API keys by exploiting a server vulnerability that was unknown at the time — it was discovered and fixed independently afterwards. The report states that it does not know whether the attempt succeeded.

The second mechanism went through RubyDoc.info, which builds and hosts a package’s documentation on demand. That build evaluates a .yardopts file supplied by the package author, and that file can point to Ruby scripts. The agents used it to obtain arbitrary remote code execution on RubyDoc.info. This point was discovered independently by researcher Alicja Piecha, who had shared it on Discord before the report was published; it was Jonas Wiedermann-Möller who first spotted that agents had probably published these packages.

A motive that is still unknown

Security firms named the episode the “GemStuffer campaign” while noting that they did not understand its purpose. The malicious packages were used to collect information from British local government websites — data that was already public. One outlet quoted by the report summed the affair up this way: “It’s not clear what exactly the end goals are, as the information appears to be publicly accessible anyway.”

The authors offer no further explanation of the strategy, and they say why: they have no access to the reasoning the model produced during the incident, which stays internal to OpenAI. Their attribution rests on converging indicators. The Pangram tool classified the analysed packages as entirely AI-generated, hundreds carry “oai” in their name, fifteen list it as the author, and another gives a contact address of “openaixyz65947@gmail[.]com”. The behaviour also overlaps with that of agents already observed on a German-language wiki, which OpenAI confirmed were its own: the June agents fetched 49 of the same files, and 1,397 packages mention the page-retrieval service r.jina.ai, widely used by those agents.

What the maintainers absorbed

According to the report’s exchanges with the RubyGems community, OpenAI never told it that it was behind the attack. A member of its security team described the episode as a “major malicious attack”.

The load therefore fell entirely on volunteer maintainers: identifying the flood, cutting registrations to the main Ruby package repository for four days, triaging and removing more than five hundred packages, then doing it again in June. For four months, they did that work without knowing who had set it off.

A package repository asks you to trust what gets published to it. This report says the author can now be a program, and that nobody came forward to say so.