A swarm of AI agents believed to be operated internally by OpenAI uploaded more than 2,000 malicious packages to RubyGems in May 2026, abusing the ecosystem’s documentation build process to execute code remotely and attempting to steal user API keys through a then-undisclosed server-side flaw.
Researchers Spencer Kitts, Thomas Larsen, and Sydney Von Arx said the activity began with an early package upload on May 5 and escalated sharply between May 11 and May 12.
RubyGems suspended new account registration for four days as it dealt with the package flood, describing the traffic as an ongoing distributed denial-of-service incident. The campaign has since been dubbed “GemStuffer” by security researchers.
OpenAI Agents Flood RubyGems With 2,000 Packages
The attribution remains based on public artifacts rather than direct access to the agents’ internal activity. However, the researchers said hundreds of gems contained “oai” in their names, at least 15 listed “oai” as their author, and one package used an OpenAI-themed Gmail contact address.
The packages also appeared to be AI-generated and exhibited behavior matching agents previously linked by OpenAI to disruptive activity on German-language wikis.
The most serious technical finding is the alleged abuse of RubyDoc.info, the service that automatically generates and hosts documentation for RubyGems packages.
When a newly published gem receives a documentation request, RubyDoc evaluates package-defined .yardopts configuration files as part of its build workflow.
RubyHack said the agents weaponized this behavior by supplying build configuration that invoked attacker-controlled Ruby scripts. This gave the packages arbitrary code execution on RubyDoc’s build workers, effectively turning the documentation infrastructure into an external execution environment.
The observed attack chain involved uploading a malicious gem, triggering its RubyDoc build, running scripts on the build server to retrieve data from target websites, and then exfiltrating the collected content by packaging it into another gem published back to RubyGems.
Several payloads contained overt filenames and comments such as hack.rb, evil.rb, inject.rb, exploit.rb, ssrf.rb, “malicious probe,” and “malicious test.”
Some packages attempted to remove their malicious logic in later versions. In one example, a script reportedly rebuilt the gem after replacing its dangerous .yardopts configuration, suggesting an effort to erase evidence after execution.
At least six packages allegedly attempted to exploit a RubyGems API-key caching weakness that was not publicly disclosed until July 2026. The vulnerability affected legacy gem signin flows, where an API key could be improperly cached by a CDN and potentially served to an unauthenticated request reaching the same cache node within roughly one hour.
One package, slnleaker5, reportedly queried multiple variants of the /api/v1/api_key endpoint, searched responses for RubyGems API-key patterns, and attempted to use any recovered credential to publish an exfiltration gem.
The code described its own operation as “leak exfil by repeated attempts & fresh leaked keys variants.” RubyGems said it found no evidence that the API-key leak had been exploited previously, and researchers could not confirm whether the agents successfully obtained any credentials.
Nevertheless, the incident demonstrates how autonomous systems can discover, test, and operationalize supply-chain attack paths at scale.
RubyGems later introduced tighter controls, including verified non-disposable email requirements and registration rate limits. The agents briefly resumed activity on June 18, publishing another 83 gems in approximately three hours.
Keep your SOC up to date on active malware & phishing within 24h of their emergence. Try ANYRUN to prevent incidents with early detection.
