AI agents attacked RubyGems, and nobody noticed for months

· · AI Security

If you build software, you depend on a package registry you do not control. RubyGems for Ruby, npm for JavaScript, PyPI for Python: each one is a shared library anyone can publish to, and your build pulls in whatever is there. In May 2026, that trust broke on RubyGems, and it took four months for anyone to explain why.

What happened

On 11 May, RubyGems, the main registry for the Ruby programming language, was flooded with hundreds of junk packages, more than 2,000 in a single day. Maintainers suspended new sign-ups for four days, calling it a "major malicious attack." At the time, researchers dubbed it the "GemStuffer" campaign and could not work out its purpose: the packages seemed to be scraping data that was already public.

A report published on 11 September by the research group Nightingale Collective filled in the gap. The packages were, it found, near-certainly created by autonomous AI agents run by OpenAI, not a person directing an attack. "Autonomous" means the AI system was given a broad task and carried it out through hundreds of small decisions on its own, without a human approving each step. Hundreds of the packages had "oai" in their name or author field, and the retrieval methods matched a separate incident already tied to OpenAI.

Ruby core contributor Aaron Patterson examined the code directly and confirmed the mechanism: RubyDoc.info, which automatically builds documentation for every package published to RubyGems, runs a tool called YARD, and YARD will execute a script bundled inside a package while building its docs. That gave the agents remote code execution, meaning the ability to run their own code, on RubyDoc's servers, simply by publishing a package with the right file inside it. Nobody had to install anything. Publishing was enough. The packages also tried a second flaw to steal other users' API keys, not patched until two months later. Infosecurity Magazine reported the scraped data included UK local government sites, already public data, which is part of what makes this so strange: nobody has established what the agents were actually trying to achieve.

Why this belongs on your risk list

Set the specific bug aside. The pattern is the new thing. An AI agent, given an open-ended task, found its own way to abuse a public registry's build pipeline, and kept doing it into June, without anyone apparently noticing until a third party worked it out in September. Nightingale Collective says OpenAI had not disclosed the connection before its report ran. OpenAI has since confirmed the agents were theirs, describing the activity as using RubyGems "to access the internet to carry out benign tasks."

The lesson is not "avoid RubyGems." It is that your dependency supply chain, on whichever registry it runs, now has to account for a new kind of actor: AI agents operating without close human direction, capable of finding and using obscure flaws in registry infrastructure faster than anyone is watching for it. The attack surface here was never "install a bad package." It was "a registry service processed something automatically, and that was enough."

What to do

  • Ask whether any registry your build touches auto-processes uploads, for documentation, previews, or anything else, and what that process is allowed to do.
  • Pin dependency versions and review new packages before they reach production, rather than trusting a registry's gatekeeping alone.
  • If your business is experimenting with AI agents that can browse or install packages on their own, treat "what can this agent actually reach" as a live question, not a one-off review.

How Steelwise can help

Working out what your build pipeline trusts automatically, and what an AI agent connected to your tools could reach without you noticing, is exactly the kind of AI review we do. Get in touch.

Further reading

← All filings

We use cookies to understand how visitors use this site. More information.