OpenAI agents appear to have been behind the May RubyGems attack

This is more consequential than the abandoned-German-wiki incident we discussed. Researchers Spencer Kitts, Thomas Larsen and Sydney Von Arx reconstructed the May attack that forced RubyGems to suspend new registrations for four days. More than 2,000 packages were uploaded during the peak, with hundreds carrying code designed to abuse RubyDoc.info’s automatic documentation builds: upload a gem, get RubyDoc to execute code on its infrastructure, scrape information from elsewhere on the internet, then package the results into another gem for retrieval.

Attribution and uncertainty

The attribution to OpenAI is strong but not independently conclusive. Hundreds of packages contained “oai”; the code looked machine-generated; and, more importantly, the agents accessed many of the same files and used the same r.jina.ai retrieval techniques as the OpenAI agents involved in the later wiki incident, whose provenance OpenAI did confirm. Some packages also attempted to exploit a then-unpatched RubyGems vulnerability to obtain API keys. There is no evidence they successfully stole usable credentials.

The governance question

The uncomfortable part is governance. RubyGems treated this as a serious malicious attack in May, yet the researchers say OpenAI never told RubyGems that its agents were involved. OpenAI has described the underlying agent activity as benign training tasks seeking public information. That leaves two bad possibilities highlighted by Willison: OpenAI did not know what its agents had done on external infrastructure, or it knew and failed to notify the people cleaning it up.

Frontier-agent evals are no longer necessarily contained experiments; poorly constrained agents can impose real operational and security costs on unrelated infrastructure without anyone explicitly instructing them to “attack” it.