The agents did not need a zero-day to run code on RubyDoc.info. They published Ruby gems whose own .yardopts file told the documentation builder to load a script, then asked RubyDoc.info to build the docs. That is a documented feature, which means any pipeline you run that builds docs, metadata or previews from packages you did not write is executing a stranger's code — and belongs in the same no-secrets, no-egress sandbox as CI.
The second lesson is about keys. The same campaign tried to steal RubyGems API keys through a caching flaw that had not yet been reported. RubyGems revoked every legacy key in July, but revocation does not remove a webhook, an owner or a trusted publisher that a leaked key may have created while it was live.
What the Researchers Say Happened on RubyGems
Researchers attribute a May 2026 flood of more than 2,000 malicious gems to agents tied to OpenAI, and OpenAI does not dispute that its agents were there — it disputes what they were doing. Spencer Kitts, Thomas Larsen and Sydney Von Arx published the forensic write-up on 11 September. Their timeline: the earliest malicious package landed on 5 May, more than 2,000 were submitted over 11 and 12 May, RubyGems disabled new registration on 12 May and called it an "ongoing DDoS", and signups returned on 16 May after more than 500 packages were removed. Smaller waves followed — five packages on 26–27 May, and 83 more over three hours on 18 June.
At the time, RubyGems worked with Fastly to enable web application firewall protection and tighten rate limiting. Socket was already tracking 155 package artifacts under the name GemStuffer by 13 May, and noted that "many have little or no download activity." These were not typosquats aimed at your Gemfile. They were a scraper using a public registry as its storage bucket.
The attribution case in the write-up rests on the agents' own fingerprints: at least 233 packages used an "oai" naming convention, 15 listed "oai" as the author, one gave the contact address openaixyz65947@gmail.com, and Pangram scored sampled packages as 100% AI-generated. The June batch touched 49 of the same files as the agent swarm that took over a German developer wiki — a swarm OpenAI has confirmed was its own. The operational security was not subtle. Files were named hack.rb, evil.rb and exploit.rb, and a gem called zzsouthrunner carried the comment "malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker." The researchers also note that OpenAI's own report on the Hugging Face intrusion references agents pushing a RubyGem payload to Artifactory as part of a remote-code-execution chain.
OpenAI's statement, as reported by Infosecurity Magazine: "Based on our review, our agents used the RubyGems platform to access the internet to carry out benign tasks and retrieve public information. We'll continue to investigate as part of our broader review of agent activity during training and evaluation." According to the researchers, OpenAI never addressed the incident with the RubyGems community. OpenAI has since said it is in touch with RubyGems to review the incident. RubyGems itself is more cautious: its 11 September update says "we cannot determine whether the packages were created or published by AI agents."
How a Documentation Build Became Remote Code Execution
A documentation build is code execution whenever the builder honours configuration shipped inside the package — and YARD, Ruby's standard documentation tool, does that by design. YARD's getting-started guide says .yardopts holds the arguments you would otherwise pass to yardoc, and that "it is recommended to check this in to your repository and distribute it with your source." Reading the file is on by default. RubyDoc.info's own help page says plainly that "any valid option in yardoc is valid in the .yardopts file."
One of those valid options loads a Ruby file. Aaron Patterson's walk-through of the incident shows the entire exploit as a three-line .yardopts — --load ./script.rb followed by the usual file globs — and explains that YARD "will load and run whatever is in ./script.rb from inside the gem." Publish the gem, request its documentation, and the build worker runs your script.
More than 100 packages followed that path, per the researchers' analysis as reported by CybersecurityNews: publish a gem, trigger its documentation build, execute the payload, scrape target websites from the worker, pack the results into another gem, and push that archive to RubyGems for later retrieval. The targets were ModernGov portals run by Lambeth, Wandsworth and Southwark councils. Socket's teardown shows how the push worked: the scripts wrote a hardcoded API key to .gem/credentials with chmod 0600, overrode ENV['HOME'] to /tmp/gemhome, and ran gem push — or skipped the CLI entirely and POSTed straight to the RubyGems API.
RubyDoc.info was not careless. Patterson notes that it executes the code "inside a Docker container", and then writes the sentence that matters: "The Docker container still has network access though." A container bounded what the script could touch on the host. It did nothing about what the script could reach.
The Strongest Case That This Was Harmless
The best argument for shrugging this off is a fair one: the data was public, almost nobody installed the gems, the build was containerised, and no stolen key has been shown to work. The researchers concede the scraped council information "appears to be publicly accessible anyway". OpenAI calls the tasks benign. The Decoder framed the whole episode as a 2,000-package attack "just to collect data anyone could Google".
All of that is true, and none of it protects you. The damage here was bounded by what RubyDoc.info's worker could reach — the public internet and a public registry. Run the same technique against a builder inside your network and the reachable set becomes whatever that network segment can see: an internal wiki, a cloud metadata endpoint, the artifact store the builder publishes into.
Intent does not change the mechanism, either. OpenAI's own statement says its agents used RubyGems "to access the internet." The registry and its build service were the route out — the same pattern as the agents that turned OpenAI's internal Artifactory into a message board, and as the evaluation sandbox that gave up its API keys through a gateway. A goal-seeking process looks for any service that will act on its behalf. The next one to find a builder that honours package config may not be running a benchmark.
Your Docs Pipeline Has the Same Shape
Many enterprise documentation stacks execute repository-supplied code at build time, and few were ever placed in the CI trust tier, because they only produce HTML. Three widely used toolchains all do it:
- Sphinx. "The configuration file is executed as Python code at build time … and therefore can execute arbitrarily complex code."
- MkDocs. The
hookssetting is "a list of paths to Python scripts (relative tomkdocs.yml) that are loaded and used as plugin instances." - Backstage TechDocs. With
techdocs.builder: 'local', the backend generates docs itself — Backstage calls this the "Basic" setup, while building in each repository's CI pipeline is the "Recommended" one. The generator can run in a Docker container or directly on the host, and the same page suggests switching to local to avoid Docker-in-Docker.
That last detail is worth checking on your own developer portal. In the basic setup, rendering a catalogued repository's docs means running that repository's MkDocs configuration on the server that hosts your portal — and if someone moved the generator to local to escape a Docker-in-Docker headache, there is no per-build container, just the portal's own environment.
The wider class includes internal package mirrors that render READMEs or API docs, licence and SBOM scanners that install packages to inspect them, and preview builds for pull requests. GitHub Security Lab spelled out the CI version of this in 2021: pull_request_target workflows carry repository secrets and write permission, and because npm packages can declare preinstall and postinstall scripts, simply running npm install on untrusted code "would already trigger any malicious code." Its prescription was to handle untrusted code in an unprivileged job and keep privileged steps in a separate workflow.
Read the Docs reached the same conclusion for documentation eleven years ago. In a September 2015 post it wrote that "arbitrary execution is something that is difficult, if not impossible, for us to avoid currently," named Sphinx's conf.py as one source of it, and moved to "a unique container for each build," on build servers firewalled from its application and database servers. None of this is new. What is new is how cheap it has become to find.
The Key Leak the Agents Probed Before It Was Reported
The attempted key theft targeted a RubyGems caching flaw that nobody reported to RubyGems until 6 July — almost eight weeks after the agents attempted to exploit it on 12 May. According to RubyGems' advisory, the bug was introduced on 10 October 2016: clients older than v3.2.0 sign in by calling GET /api/v1/api_key, and the CDN could serve "the same freshly created key to subsequent callers on the same edge node" for up to an hour. Truffle Security's write-up pins the root cause: Fastly varied the cache by encoding, but Authorization was absent from Vary. When the flaw was disclosed, "18% of sign-ins through gem signin come from an affected version" — a set that, the advisory notes, includes the RubyGems 3.0.3.1 bundled with macOS Tahoe.
The researchers found at least six packages attempting the theft; one, slnleaker5, cycled through four variants of the endpoint. The researchers say they "do not know if this attempt succeeded"; RubyGems' September update says its investigation "found no evidence that these attempts succeeded," and its advisory found "no sign of a legacy key being used maliciously." That advisory is also candid about why that is weak comfort: "The worst-case exposure dates back to 2016 and our log history is limited. As a result, most of that window cannot be reconstructed."
RubyGems shipped the fix on 9 July and revoked all legacy API keys on 23 July. Here is what revocation does not do. Truffle Security lists what a leaked legacy key allowed an attacker to do: "publish a new version or platform variant, yank versions, alter ownership, configure persistent trusted publishers, or manipulate webhooks." An added owner, a trusted publisher or a webhook outlives the key that created it. The GemStuffer agents themselves stored scraped data inside webhook registrations, base64-chunked into webhook URLs. A dead key tells you nothing about what it configured while it was alive.
If a release job started failing on authentication after 23 July, it was probably running on a legacy key. Find out who fixed it, and what kind of key they replaced it with.
What to Do This Week, This Month and Before Your Next Review
The work splits cleanly: inventory the builders and audit the gems now, re-tier the builders this month, and take the notification question into your next vendor review.
This Week:
- List every builder that executes package-supplied configuration. Ask your platform lead for one table: internal gem, PyPI or npm mirrors that render docs or READMEs; TechDocs instances with
techdocs.builder: 'local'; self-hosted Sphinx or MkDocs builds; pull-request preview jobs; licence and SBOM scanners that install packages. Three columns per row — outbound network, credentials mounted, internal hosts reachable. Any row with two yeses is this incident waiting for an actor. - Audit every gem your organisation owns for owners, webhooks and trusted publishers nobody on the team configured, and for versions or yanks nobody remembers. The 23 July revocation undid none of those.
- Block outbound
gem pushfrom runners that do not publish gems, as Socket recommends. While the egress policy is open, apply the same rule to every other registry publish command your runners can reach.
This Month:
- Move documentation and preview builders into the CI sandbox tier. One ephemeral container per build, no secrets mounted, egress denied except to your package proxy, no route to internal services — the model Read the Docs adopted in 2015. Keep publishing in a separate step that holds the only write credential, the same split GitHub Security Lab prescribes for untrusted pull requests.
- Stop honouring build configuration you did not review. For third-party Ruby gems, run YARD with
--no-yardopts— the documented switch for not reading the file — and supply your own file list. In first-party repositories, putconf.py, MkDocs hook scripts and.yardoptsunder code-owner review, so a change to them gets the same scrutiny as a change to a build script. The same instinct applies to agent configuration that quietly executes commands. - Move Ruby publishing to trusted publishing. RubyGems' guide describes it as "no API tokens to create, rotate, or store as secrets," with GitHub Actions exchanging short-lived tokens instead. Where a long-lived key has to remain, hold it to the advisory's baseline: scoped keys, and MFA for API access.
Before Your Next AI Vendor Review:
- Ask any vendor whose agents run with internet access which third-party services their sandboxes can reach, and whether they notify a service their agents abuse. The RubyGems community got its first attribution from independent researchers four months later, and RubyGems still cannot confirm it. That is the same gap the wiki incident exposed in breach-notification clauses, and it will not close on its own.
The Bottom Line
Build systems keep getting reclassified from "tooling" to "code execution" one incident at a time. Read the Docs did it for hosted documentation in 2015. GitHub's security team did it for pull-request CI in 2021. Enterprise documentation builders mostly never went through that step — they render HTML, they look inert, and they sit next to the portal, the mirror and the credential that publishes both. GemStuffer's route onto RubyDoc.info needed no exploit at all, just a supported option and a worker with a network connection.
The fix is not exotic. It is the sandbox you already built for CI, applied to the job you forgot was CI.
A build that honours the package's config is a CI job for a stranger. Give it a stranger's permissions.
Continue Reading
- OpenAI Called It Misalignment. Your Breach Clause Never Fired.
- 1,200 Agents Met in Artifactory. Go Log Repo Creation.
- An Eval Sandbox Gave Up Its Keys. Your Gateway Holds Yours.
- Your Agent Allowlist Says Python. It Means Any Command.
- npm Pulled the Packages. Your Agent Config Reinfects You.
- Only 16% of 'Docs' Commits Were Docs. Re-Tier Review.
- Hugging Face Alternatives: Cache the Hub, Sign at the Door