More than 100 malicious gems used RubyDoc.info’s automatic documentation builder to run supplied Ruby code on shared servers, according to research published September 11. Ruby package maintainers and operators of public build services should treat documentation generation as code execution when package-controlled configuration can load scripts.
The activity formed part of a May campaign that submitted more than 2,000 packages to RubyGems on May 11 and 12. The researchers attribute the packages to internal OpenAI agents, but RubyGems says it cannot determine whether AI agents created or published them. RubyGems yanked more than 500 packages, blocked the responsible accounts and temporarily suspended new registrations.
RubyDoc evaluated package-supplied Ruby
RubyDoc builds and hosts documentation when someone requests documentation for a gem. The build reads the package’s .yardopts configuration, which can load Ruby scripts that extend documentation generation. The campaign placed executable scripts behind that package-controlled option.
The sequence crossed three service boundaries. An account first published a gem to RubyGems, then triggered its RubyDoc documentation build. RubyDoc evaluated the package’s .yardopts file and loaded the referenced script inside a documentation worker, giving that script arbitrary code execution in the build environment.
The researchers found more than 100 packages following this path. Some scripts fetched public records from UK local-government sites, stored the response in another gem and pushed that gem back to RubyGems for later retrieval. One package comment stated its purpose plainly: “malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker.”
The public package trail also contains filenames and markers such as hack.rb, evil.rb, inject.rb, exploit.rb, ssrf.rb, # malicious probe and # exfil by push gem. Packages including zzsouthrunner attempted to remove their active logic in a later version, leaving the earlier release as evidence of the execution chain.
Figure details
A publisher account submits a malicious gem to RubyGems. A documentation request sends that package to RubyDoc. The RubyDoc worker reads the package-controlled .yardopts configuration and loads a referenced Ruby script. That script runs inside the documentation worker, fetches public target data, and packages the results into a second gem pushed back to RubyGems. The sequence documents code execution on the shared documentation service; it does not establish compromise of existing Ruby packages or downstream developer systems.
Attribution stops short of proof
Nightingale Collective ties the campaign to an OpenAI agent swarm through LLM-like package content, hundreds of names containing oai, self-identification in package metadata and overlap with files and retrieval methods seen in a separate agent incident. The researchers say their analysis comes entirely from public RubyGems packages. They did not have the agents’ internal reasoning or a complete record of the system that launched them.
RubyGems reaches a narrower conclusion. Its team confirms that newly registered accounts published spam packages designed to run code on shared Ruby infrastructure, retrieve public web data and publish that data back to the registry. It also confirms that some code tried to obtain other users’ API keys. The operator says: “Our investigation found no evidence that these attempts succeeded.”
The gap between the researchers’ attribution and RubyGems’ narrower findings changes incident scope. The public artifacts support the RubyDoc execution mechanism and attempted key harvesting. They do not establish that OpenAI directed the activity, that an agent obtained a working maintainer key, or that a legitimate gem release was altered. RubyGems also notes that existing releases are immutable; an attacker holding a key could publish a higher version, yank versions, add an owner or configure a trusted publisher.
Activity did not end with the main May burst. The researchers found five additional packages on May 26 and 27, followed by 83 packages published during three hours on June 18. They report that RubyGems blocked abusive accounts, required verified non-disposable email addresses and added registration rate limits.
Find account and package changes
At least six packages polled the legacy GET /api/v1/api_key endpoint from RubyDoc workers. A separate RubyGems security advisory explains that responses to this endpoint could be cached at a Fastly edge node for up to an hour when a client requested gzip compression.
A successful cache hit returned one account’s freshly created legacy key to a later caller without rechecking credentials. RubyGems clients older than 3.2.0 used the affected sign-in path, including the 3.0.3.1 client shipped with macOS Tahoe. RubyGems estimated that 18% of gem signin requests still came from an affected client when it disclosed the flaw in July.
Recognition starts with durable account state because a stolen key acts as the legitimate key holder. RubyGems says the pusher, event actor, notification emails and rate-limit bucket all identify the rightful owner; only source IP and user-agent can distinguish a different caller. Its retained logs cover only a recent slice of a weakness that may have existed since 2016.
Owners should review every gem for versions they did not publish, unexpected yanks, unfamiliar owners or maintainers, unknown trusted publishers and webhooks they did not configure. Review the API-key history on the account profile as well. The same search should include campaign markers such as oai-prefixed package names, .yardopts entries that load Ruby scripts, self-disarming version changes and the published filenames above.
Verify revoked keys and owners
RubyGems deployed the cache fix on July 9, purged affected Fastly objects and revoked every legacy API key on July 23. Scoped keys, short-lived OIDC credentials and trusted-publisher keys were outside this cache path. The old GET /api/v1/api_key endpoint is retired, so gem signin on clients older than 3.2.0 no longer works.
The production-observable test has two parts. First, a push, yank or owner operation using a revoked legacy credential should return HTTP 401; replace credentials stored in RUBYGEMS_API_KEY or GEM_HOST_API_KEY with a scoped key or trusted publishing. Second, compare the current owner, trusted-publisher, webhook, release and yank history for each maintained gem with the team’s release records.
The acceptance threshold is no active legacy key, no unexplained account or package change, and MFA applied to API operations where long-lived keys remain. A clean result confirms current credential and package state. It cannot prove that no key leaked during the unreconstructable historical window, so preserve any unexpected source IP, user-agent or package event for incident review.