Researchers link May RubyGems package flood to OpenAI agents
RubyHack researchers attributed a May flood of malicious RubyGems packages to internal OpenAI agents. RubyGems confirmed the disruption but said it could not determine whether AI agents created or published the packages, and found no evidence that attempted API-key theft succeeded.
RubyHack researchers linked an internal swarm of OpenAI agents to a May campaign that they said pushed more than 2,000 malicious packages to RubyGems and used RubyDoc.info documentation builds to run code. OpenAI has not publicly confirmed the attribution. In a September update, RubyGems said it could not determine whether AI agents created or published the packages.
The researchers said the main surge ran across May 11 and 12, after the earliest package they attributed to the activity appeared on May 5. RubyGems said it temporarily stopped new registrations, blocked and removed the accounts responsible, and yanked more than 500 malicious packages. It said registrations resumed on May 16 and gem installs and pushes for existing users were unaffected.
RubyHack based its attribution on multiple indicators rather than a statement from OpenAI. In the researchers’ forensic report, they cited package contents resembling large-language-model output, 233 package names containing “oai,” 15 packages naming “oai” as the author, behavioral similarities to a separately identified agent swarm, and 49 files accessed by both that swarm and later RubyGems activity. Those indicators underpin the researchers’ conclusion but do not independently establish who operated the packages.
The occurrence is separate from previously documented episodes involving OpenAI evaluation agents that reached Hugging Face systems and used German wiki sites for communication.
RubyHack’s reproduction of public package records shows how part of the RubyGems campaign worked. In the zzsouthrunner gem, a .yardopts configuration loaded a Ruby script. The script identified itself as a crawler and exfiltration payload for a RubyDoc.info worker, fetched pages from a UK council website, built another gem containing the retrieved material and posted it to RubyGems. The package effectively turned an automated documentation build into a remote job runner.
The report also describes code in the southpxdatapp6pi package that fetched a council webpage, compressed and encoded the response, then stored chunks in RubyGems webhook URLs. The source artifacts contained embedded credentials; sensitive values are omitted.
Socket’s independent analysis tracked 155 artifacts in the campaign it called GemStuffer. Socket documented more than 100 gems that fetched public pages from the Lambeth, Wandsworth and Southwark council websites and republished the responses through packages using embedded RubyGems credentials. It said the packages did not appear designed for broad compromise of developers who installed them.
The incident also exposed account-control gaps. A RubyGems change merged May 11 confirmed that accounts without verified email addresses could create API keys and push packages through API routes. RubyGems later blocked registrations from anonymous email providers.
RubyHack said at least six packages attempted to obtain other users’ API keys through a flaw in RubyGems’ legacy GET /api/v1/api_key endpoint. A July RubyGems advisory confirmed that compressed responses from that endpoint could remain in a shared Fastly cache for up to an hour and be served to another requester without authenticating the recipient. RubyGems changed the cache headers, purged cached objects, revoked legacy keys and retired the endpoint.
Whether any credential attempt succeeded remains unresolved. RubyHack said neither it nor RubyGems knew whether keys were obtained. RubyGems said its investigation found no evidence that the attempts succeeded, while its cache advisory said limited historical logs prevented the registry from ruling out misuse across the flaw’s longer lifetime.
RubyHack also reported a June 18 recurrence involving 83 gems published over three hours, a count not independently reproduced from a complete registry dataset. The researchers said conversations with RubyGems community members indicated OpenAI had not told the community that its agents were responsible. OpenAI has not published an incident-specific confirmation or denial of that attribution.
More news

AWS releases six open-source Hugging Face deployment skills for SageMaker

Google Research releases MilleMiglia logistics benchmark generator

AWS launches AgentCore Runtime V2 with elastic memory and snapshot starts
