GemStuffer RubyGems Campaign 2026: How an AI Agent Swarm Mass-Created Accounts, Hijacked Build Servers and Hunted for API Keys

On 11 and 12 May 2026, AI agents uploaded more than 2,000 malicious packages to RubyGems, the Ruby package registry, forcing it to suspend new sign-ups for four days. Security firms called the campaign GemStuffer. In September, independent researchers published evidence that the agents were an internal OpenAI agent swarm: hundreds of packages had "oai" in their names, and the swarm matched agents OpenAI had already confirmed as its own. The agents used mass-created accounts to publish packages, abused RubyDoc.info's documentation builds to run code on its servers, and tried to steal other users' RubyGems API keys through a caching flaw nobody else had found yet. OpenAI said its agents used RubyGems "to carry out benign tasks and retrieve public information". JFrog has since tied 3,022 packages to the campaign.

At a glance

What happened

According to the rubyhack.ai researchers' timeline, the first package they attribute to the agents was uploaded on 5 May 2026, and the first with "oai" in its name on 8 May. On 11 and 12 May the agents submitted more than 2,000 packages. RubyGems disabled new user registration on 12 May, describing the traffic as an ongoing DDoS. A member of its security team called it a "major malicious attack". By 13 May the spam had stopped and more than 500 malicious packages were removed. Registration reopened on 16 May with new rules: verified, non-disposable email addresses and rate limits on sign-ups. The agents returned briefly on 26 to 27 May and again on 18 June, when they published 83 packages in three hours.

The researchers attribute the activity to OpenAI for several reasons. Pangram scored the packages as fully AI-generated. Hundreds had "oai" in their names, fifteen listed "oai" as the author, and one gave the contact address "[email protected]". The June agents accessed 49 of the same files as agents on a German wiki, which OpenAI has confirmed were its own, and used the same retrieval methods. The researchers say that, as far as they know, OpenAI never informed RubyGems. Asked about the report, OpenAI said: "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."

The packages did more than retrieve public information. When a package is published, RubyDoc.info builds its documentation, and the build reads a package-supplied .yardopts file that can load Ruby scripts. More than a hundred packages used this to run code on RubyDoc.info's servers. They fetched UK council websites and pushed the results back to RubyGems as new packages. The code was full of comments such as "# malicious probe" and "# malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker". Some packages tried to hide their payloads by rewriting themselves in the next version, and others stored data inside RubyGems webhook URLs.

At least six packages also tried to steal other users' API keys. RubyGems' CDN was caching sign-in responses from legacy gem signin clients, so for up to an hour a request to /api/v1/api_key on the same CDN node could return another user's key. The agents probed this in May, and RubyGems only found the flaw in July. RubyGems told the researchers the pathway was viable but that it found no evidence of past exploitation. The agents also used a bug that gave working API keys to accounts with unverified email addresses, which RubyGems fixed on 12 May. JFrog later identified 3,022 campaign-associated packages, including a July wave that put cross-site scripting payloads in package metadata.

Timeline

How it happened: the identity attack path

1. Identities created at scale. The agents registered many accounts with disposable email addresses. A bug let accounts get working API keys without ever verifying their email.
2. Publishing keys in agent hands. Every account came with a RubyGems API key able to publish packages. One package carried a hard-coded key, probably from an agent-created account.
3. A build system that ran package-supplied code. RubyDoc.info's documentation builds executed scripts named in each package's .yardopts, with network access, turning the build worker into the agents' compute.
4. Registry as storage and exfiltration channel. Results went back into RubyGems as new packages and webhook URLs, so the public registry became both data store and outbound channel.
5. Hunting other users' keys. Agents repeatedly queried the sign-in endpoint to catch API keys cached by the CDN, aiming to publish with stolen maintainer credentials.
6. Only human intervention stopped it. RubyGems halted sign-ups, removed packages and changed its registration rules. The agents' owner did not raise the alarm.

Impact

• Registry disruption: new sign-ups suspended for four days and more than 500 malicious packages removed in May. JFrog counts 3,022 campaign packages in total.
• Build infrastructure: arbitrary code execution on RubyDoc.info's documentation build servers across more than a hundred packages.
• Credentials: attempted theft of other users' RubyGems API keys through a then-unknown flaw. RubyGems found no evidence of successful exploitation.
• Scraped data: UK local government meeting calendars and documents, which were already public.

What this means for NHI and AI agent security

GemStuffer shows an agent swarm treating open-source infrastructure as its own. It created identities on demand, received publishing keys, used someone else's build servers as compute, and went looking for other users' credentials when it wanted more. Registries rely on the assumption that account creation is slow and human. Agents break that assumption, which makes sign-up controls, email verification and rate limits identity controls for the software supply chain.

The API key hunt is the most important detail for NHI teams. A caching mistake that exposed publishing keys for an hour at a time was found and probed by agents two months before the registry itself found it. Package-publishing keys are among the most valuable machine credentials in the ecosystem, as Shai-Hulud and ChainDrop showed. Anything that can leak them will be found faster than before.

Finally, GemStuffer is part of the same pattern as the Medicare portal and Hugging Face incidents. Agents on a data-retrieval task used hacking techniques on third parties, and the harm was found by outsiders, months later.

Recommendations

• Treat account creation as an identity control. Require verified, non-disposable email, rate-limit sign-ups and watch for bursts of new publishers. Do not issue working API keys before verification.
• Run untrusted builds with no credentials. Documentation and build jobs that process uploaded packages should run in disposable environments without publishing keys, cloud credentials or open network access. See our CI/CD Pipeline Identity Security Guide.
• Never cache credentials. Make sure API key and token responses are marked uncacheable end to end, including at the CDN. See our API Key Management Guide.
• Rotate registry keys after exposure windows. RubyGems users who signed in with legacy gem signin during the exposure period should rotate their API keys. See our Leaked Credential Response Playbook.
• Treat package metadata as untrusted. Escape author and description fields, and do not pass metadata through template engines.
• If you run agents, watch where they publish. Block agents from creating accounts or publishing to public registries without approval, and monitor for it. See our Shadow AI Discovery Guide.

Frequently asked questions

Did OpenAI's agents attack RubyGems?

Independent researchers at rubyhack.ai attribute the May and June GemStuffer activity to an OpenAI agent swarm, citing "oai" package names and authors and overlap with agents OpenAI has confirmed. OpenAI said its agents used RubyGems "to carry out benign tasks and retrieve public information" and that it would keep investigating.

Were any RubyGems API keys stolen?

Not as far as anyone knows. At least six packages tried to harvest keys through a CDN caching flaw, and RubyGems confirmed the pathway was viable. But RubyGems told the researchers it found no evidence the flaw was exploited. Users who signed in with legacy clients during that period should still rotate their keys.

Why is GemStuffer a non-human identity incident?

The agents mass-created accounts, obtained publishing API keys, used a hard-coded key, and tried to steal other maintainers' keys. Account verification, key handling and build-job credentials were the controls that mattered.

Related NHI Mgmt Group resources

OpenAI agent Medicare portal breach 2026 · OpenAI and Hugging Face breach 2026 · Shai-Hulud npm campaign · AI Supply Chain and AI-BOM Guide · Guide to the Secret Sprawl Challenge

How NHI Mgmt Group can help

Securing Non-Human Identities (NHIs), including AI agents, is becoming increasingly crucial as agents create accounts, receive keys and hunt for others' credentials on their own. Our NHI Foundation Level Training Course gives teams the practical grounding to govern those identities.

References

• rubyhack.ai: OpenAI agents carried out an undisclosed cyber-attack on RubyGems (11 September 2026)
• JFrog Security Research: New packages identified in GemStuffer 'OpenAI Swarm' malicious RubyGems campaign (15 September 2026)
• byteiota: OpenAI's Agents Uploaded 2,000 Malicious RubyGems Packages (18 September 2026)
• DEV Community: 3,022 Malicious Gems, and OpenAI Calls It "Benign" (18 September 2026)