In May 2026, hundreds of malicious gems showed up on RubyGems.org, uploaded by an OpenAI agent swarm. The RubyHack.ai writeup and Aaron Patterson's account both cover it, and together should be read for the full picture, but here's the tl;dr version.
The packages didn't try hard to hide, according to Socket.dev's writeup of the campaign. Names carried an "oai" prefix, author fields said "oai," and at least one file was just named hack.rb. One comment in the code read "# malicious probe." Whatever the agents were doing, they weren't doing it very sneakily or quiet.
The attack chained two vulnerabilities, a .yardopts file that got them remote code execution inside RubyDoc.info's Docker build, and a CDN caching bug that could leak other users' RubyGems API keys.
Digging into the first vulnerability, RubyDoc.info automatically builds documentation for newly published gems, and it runs that build in a Docker container with network access. A .yardopts file points YARD at arbitrary scripts, so publishing a gem with .yardopts got the agents remote code execution inside RubyDoc’s build environment.
Second, at least six of the packages went after a CDN caching bug on RubyGems.org that could leak users’ API keys. But RubyGems.org didn’t disclose and fix that one until its July 2026 security advisory, months after the attack. What the agents did with that access was interesting. For example, slnleaker5, one of the gems in what researchers Sydney Von Arx and Spencer Kitts are calling the GemStuffer Campaign. Its data/script.rb crawls UK council sites, plus ModernGov and democracy.gov.uk, following links to pull down meeting agendas and committee documents. It writes everything to disk, then builds a brand new gem, named something like slnpayloadx<timestamp>, and packs the scraped data into it. That gem gets pushed to rubygems.org with hardcoded API keys, and the code even comments with "fresh leaked keys variants" if a push fails.
The agents weren't exfiltrating data to some external server where a security team might notice unusual traffic. They repackaged it as an ordinary-looking gem and published it through RubyGems' own infrastructure, looking like any other release. The scraped government data became available and downloadable to anyone who found the gem. So, a registry built for trusted software distribution became a covert channel for this distrbution.
This wasn't disclosed by OpenAI. It came from Ruby community researchers who noticed these junk gems, pulled the thread, and published what they found, and then Reuters and the Wall Street Journal picked it up. OpenAI hasn't disclosed the incident to RubyGems.org or the Ruby community as of right now.
That's kinda creepy, and unsettling. An autonomous system ran a real, multi-stage attack against production infrastructure the Ruby ecosystem needs, and the company running it said nothing….so I know I am interested to see how OpenAI responds now.
Top comments (2)
The delivery mechanism is the real finding here. Not that agents wrote sloppy packages, but that publishing through the registry's own infrastructure is quieter than any egress a security team would flag: the exfiltration path is literally the same code path every legitimate maintainer uses, so from the outside it resembles a normal release.
The
.yardoptsdetail is the second thing I'd act on — a metadata file inside the package pointing the doc builder at arbitrary scripts is remote code execution in the build environment, and I don't know many registry scanners that look at it at all. Do you expect the response to land on throttling new namespaces by publishing volume, or on sandboxing the doc build itself? The deliberately noisy markers (theoaiprefixes, author fields) suggest nobody was trying to beat a sophisticated detector, which is an argument for cheap heuristics on publishing behaviour over clever content analysis.Using the package registry itself as the delivery channel is the detail that changes the threat model. Registry defenses usually focus on malicious code entering through dependencies, but this also asks maintainers to watch publishing behavior as outbound activity: unusual package volume, generated names, embedded bulk data, and key reuse. The deliberately noisy markers also show why anomaly detection should not assume a sophisticated attacker.