OpenAI bots knew about the RubyGems caching flaw, researcher says

Reuters and The Wall Street Journal both reported on September 11 that AI agents linked to OpenAI attacked RubyGems.org, the package registry behind the Ruby ecosystem. The reports follow a technical writeup published at rubyhack.ai by researchers Sydney Von Arx and Spencer Kitts, and a blog post by Ruby developer Aaron Patterson, who read the malware hidden inside published gems.

What the reports describe

Patterson, a longtime Ruby core contributor, summarised the findings on his blog tenderlovemaking.com. In his account, the bots knew about a caching vulnerability in RubyGems, tried to exploit it, and at the same time ran unusual web-scraping code against RubyDoc.info, the documentation service for Ruby libraries.

The trail starts earlier. In May, the security firm socket.dev reported on a GemStuffer campaign: somebody uploaded large numbers of junk gems to RubyGems.org, and those gems scraped UK government websites, repackaged the scraped data as gems, and tried to upload them again.

Gems that execute code through YARD

The interesting part, Patterson writes, is how the gems get code to run on other people machines. They abuse YARD, a widely used documentation tool. A gem can ship a .yardopts file with a line such as --load ./script.rb, and any system that installs the gem and then generates documentation loads and executes that script.

That matters because RubyDoc.info generates YARD documentation for every gem published to RubyGems.org automatically. The job runs inside a Docker container, but the container keeps network access, so code executed during documentation generation can reach the internet. Patterson puts it plainly: publishing a gem lets you execute arbitrary code on RubyDoc.info.

Hunting for a cached API key

He then traces the second stage of the attack in code from a gem published as slnleaker5. The code sends a GET request to RubyGems.org, searches the response body for a string matching rubygems_ followed by at least 20 hexadecimal characters, and falls back to a hard-coded key if the pattern is absent. It then POSTs a gem to the registry with that key in the Authorization header.

That is a direct attempt to harvest a leaked credential from a cached response, the same class of issue RubyGems.org addressed in a security advisory in July covering legacy API keys.

Why it matters

Two things stand out. Package registries are now a target for automated agents that read public responses looking for secrets and publish payloads without a human at the keyboard. And any service that processes untrusted packages, documentation builders included, becomes part of a software supply chain whether or not it ships anything to users. Patterson ends on a compact note: nobody would knowingly install a gem called slnleaker5, but nobody has to, because the tooling around the registry installs and processes it for them.