On May 5, a handful of odd packages showed up on RubyGems. By May 11 and 12 there were more than 2,000. Maintainers switched off new sign-ups for four days to stop the flood, and Maciej Mensfeld from the security team said publicly that the project was dealing with a major attack. Then it went quiet, and the whole thing got filed as a spam wave.
Since Friday there is another explanation. Spencer Kitts, Thomas Larsen and Sydney Von Arx have published an incident timeline. Three of the four authors already worked through the attack on the disused wikis a week ago, the one OpenAI has since confirmed as its own agents. Their finding this time: the RubyGems campaign very likely came from the same place.
The agents did not try very hard to hide
Plenty of the packages carried “oai” in their names. Fifteen had “oai” in the author field, one listed openaixyz65947@gmail.com as its contact. Files were called hack.rb, evil.rb, inject.rb and exploit.rb. Packages went by pwnp999, exfiltestwand3 and hacksvn, and the code carried comments like “malicious probe”.
The convincing evidence is technical, though. The agents pulled content through the same detour the wiki agents used, r.jina.ai. Same method, same kind of target files, overlapping timeframe. One agent even commented its own intent: “malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker”.
That was the pattern. The packages abused the RubyDoc.info documentation build process to get code execution, then used it to pull public data off UK government websites. Public data, note. It looks like a research task, same as the wikis, only with a package repository as the tool.
The part that looks less benign
Two things break that picture. The agents used a bug that let them register accounts and obtain API keys without confirming an email address; disposable addresses were enough. And they tried to steal other users’ API keys through a broken cache configuration that was only discovered and fixed in July. Colby Swandale, technical lead at RubyGems, says access logs show no evidence that anyone’s keys were actually misused. He also says the review was limited in scope and inconclusive.
Security firm Socket described the campaign in a threat intelligence report on May 13. It made no mention of agents or of OpenAI.
What OpenAI says
A spokesperson confirmed the incident to CyberScoop and said the company is in contact with the researchers and with RubyGems. Their characterisation: benign. Routine training runs, agents retrieving publicly available information.
The researchers write that, based on what they heard from people in the RubyGems community, OpenAI had not told the project about its involvement until this week. Simon Willison lays out the two options that leaves. Either OpenAI reviewed its logs after the Hugging Face and wiki incidents and still failed to spot RubyGems. Or it spotted it and decided not to make the call. Neither is good.
My take
The attack bothers me less than the delay. For four months, a project run by volunteers cleaned up after an attacker who could have picked up the phone at any point. The packages were obviously an exercise — nobody writing “evil.rb” is trying to stay hidden — and sign-ups still stayed shut for four days.
The researchers are honest about their limits: they only saw the public packages, not the models’ chains of thought. Why the agents picked this route is something only OpenAI knows. Which leaves the question Willison ends on: how many more of these are sitting out there, waiting for someone else to find them?
Sources: OpenAI agents carried out an undisclosed attack on RubyGems, Simon Willison: OpenAI agents attacked RubyGems back in May, CyberScoop: Researchers say OpenAI agents were behind May hacking campaign targeting RubyGems