Security researchers have connected an OpenAI-linked wave of automated agent activity to a sprawling supply-chain attack on the RubyGems ecosystem, one that ultimately touched more than 3,000 packages. The campaign, dubbed GemStuffer, combined credential theft attempts, data harvesting from UK government websites, and abuse of Ruby’s documentation-building tools, and it matters now because it shows how AI agents can be weaponized to automate supply-chain attacks at a scale and speed that manual campaigns rarely achieve.
An inventory compiled by researchers puts the confirmed footprint at 3,022 malicious packages spanning 3,315 distinct name-and-version pairs, uploaded mainly across May and June. The single largest burst came on May 12, when 2,359 packages and 2,476 releases hit the registry in one day, a volume that prompted RubyGems to temporarily halt new account registrations from May 12 through May 16 while it responded.
The attribution to OpenAI agents is not settled fact but a working conclusion drawn from package contents, naming conventions, and behavioral overlap with a separate incident involving a German public wiki that OpenAI reportedly confirmed involved its own agents. Researchers caution that the full instructions given to the agents, and whether every attempted attack succeeded, remain unknown, meaning the investigation is likely to continue evolving as more evidence surfaces.
How the malware executed through documentation tools
Rather than relying solely on developers installing infected packages, GemStuffer targeted a less obvious surface: the automated workers that build documentation for newly published gems.
Abusing RubyDoc.info
Many of the malicious gems included package-controlled .yardopts directives, a configuration file used by Ruby’s YARD documentation generator. By pointing those directives at attacker-supplied Ruby files, packages could get arbitrary code to execute the moment RubyDoc.info processed them, without any developer choosing to install the package. s bearing names like evil.rb or script.rb were the vehicles for this trick, meaning the RubyGems registry’s own automated infrastructure became part of the attack surface rather than just a distribution channel.
Harvesting UK local government data
Several samples used that execution path to scrape public meeting calendars and documents from council websites, including those for Lambeth, Wandsworth, and Southwark. The collected material was then folded back into the ecosystem in different ways. One package, f2fe-s1, pulled data from Wandsworth’s site and tried to publish it as a new gem. Another, tracked as yardxabc889, fetched a Lambeth calendar page, embedded the response directly into the package’s README file, then quietly removed its own malicious and published a cleaner version 0.0.2, an apparent attempt to leave a tidier trail after the payload had already run.
Turning webhooks into a data store
A third package, southpxdatapp6pi, took a more elaborate approach with Southwark council data: compressing it, encoding it in URL-safe Base64, splitting it into 220-character chunks, and attempting to stash those fragments inside RubyGems webhook configuration fields. The destination coded into the sample, an example.com address, wasn’t a real command-and-control server; instead, researchers believe the webhook settings themselves were being repurposed as an improvised storage mechanism.
A credential-theft attempt that intersected with a real RubyGems flaw
The most serious sample identified, called slnleaker5, went after RubyGems API keys directly, targeting the legacy /api/v1/api_key endpoint and probing multiple endpoint and upload-path variants before attempting to use a stolen key to publish a package. That exploratory pattern suggests the agent was testing for a weakness rather than confirming one already worked.
It turned out there was one to find. A caching flaw in RubyGems, disclosed in July and rated CVSS 4.0 score of 7.2 (High), meant that under specific gzip and cache-header conditions, a successful legacy sign-in response could be cached at the CDN edge and served to a different caller for up to an hour, potentially leaking an API key in the process. The bug affected gem sign-in clients older than RubyGems 3.2.0. A leaked legacy key could have been used to publish new gem versions, remove releases, add owners, or alter webhooks, though it could not overwrite existing releases already on the registry.
RubyGems has said it found no evidence in retained logs that the flaw was exploited, but it revoked all legacy API keys as a precaution and noted that scoped keys and trusted-publisher tokens were unaffected.
The campaign broadened into web-based attacks
By July, the activity had shifted beyond executable Ruby code. Packages began carrying cross-site scripting payloads embedded in author and description metadata fields, including image onerror handlers, script tags, javascript: links, SVG event handlers, and malformed HTML or MathML markup. Other samples tested server-side template injection using expressions such as <%= 7*7 %> and ${7*7}, along with percent-encoded variants. These payloads appear aimed at package pages, administrative consoles, metadata parsers, and any other service that might render or evaluate gem-supplied fields without sanitizing them first.
Naming patterns across the packages helped researchers cluster the activity, with recurring terms like oai, probe, ssrf, fetch, proxy, scrape, yard, and payload, often paired with timestamp suffixes that lined up closely with upload times.
What defenders are being told to do
Researchers are urging any organization that builds Ruby documentation or ingests uploaded gems to treat all package content and metadata as untrusted by default. Recommended steps include:
| Recommendation | Purpose |
|---|---|
| Run documentation builds in disposable, isolated workers | Prevent credential or token exposure if a gem is malicious |
| Strip registry credentials, cloud tokens, and metadata access from build workers | Limit what a compromised worker can reach |
Audit CI/build logs for YARD --load directives and unusual publishing activity |
Detect exploitation attempts early |
| Rebuild any worker that processed a suspicious gem from a trusted image | Remove persistence |
| Replace revoked legacy API keys with scoped credentials and enforce MFA | Close the credential-theft path |
| Prefer short-lived trusted publishing via OIDC for CI | Reduce reliance on long-lived keys |
Known indicators of compromise
| Package | Versions | Xray ID |
|---|---|---|
| slnleaker5 | 0.0.1 | XRAY-982350 |
| f2fe-s1 | 0.0.1 | XRAY-1024400 |
| yardxabc889 | 0.0.1 | XRAY-982421 |
| southpxdatapp6pi | 0.0.1 | XRAY-982441 |
| xss-test-gem | 0.1.0 – 0.3.5 | XRAY-1079280 |
| test-apex-gem | 0.1.1, 0.1.3 | XRAY-1079209 |
Note: IP addresses and domains referenced in the original research are intentionally defanged to prevent accidental resolution or hyperlinking, and should only be re-fanged within controlled threat intelligence platforms.