Inside the OpenAI-RubyGems Incident: Did AI Agents Attack RubyGems?

Umut Bayram | 6 MIN READ

| September 15, 2026

Key Takeaways

A May 2026 malicious package campaign forced RubyGems to suspend registrations and withdraw more than 500 gems.
More than 2,000 packages were submitted in two days using accounts created with disposable email addresses.
Packages abused RubyDoc.info documentation builds to run code on its servers and republish harvested web data.
At least six packages tried stealing other users' API keys through a cache flaw fixed in July.
Package names, shared target files, and explicit code comments link the campaign to OpenAI agents.
RubyGems could not independently confirm attribution and found no evidence that any API key theft succeeded.

In May 2026, a malicious package campaign forced RubyGems to suspend new registrations and remove hundreds of packages [1]. Researchers later linked the activity to OpenAI agents, reporting unauthorized code execution and attempted API-key theft [2]. OpenAI acknowledged its agents’ use of RubyGems to retrieve public information [3]. RubyGems could not independently confirm attribution and found no evidence of successful key theft.

Despite these unresolved questions, the incident raises concerns about how frontier AI agents interact with real infrastructure. This post examines the incident, the available evidence, and the implications for security teams as security validation becomes increasingly important.

Event Timeline

Date	Event
May 5	The earliest known package linked to the campaign was uploaded to RubyGems.
May 8	The first known package with oai in its name appeared.
May 11–12	More than 2,000 packages were submitted to RubyGems.
May 12	Some packages tried to steal other users’ API keys by exploiting a flaw in how RubyGems stored older sign-in responses. RubyGems stopped new account registrations.
May 13	The spam had stopped. RubyGems had blocked and removed the accounts responsible and withdrawn more than 500 malicious packages.
May 16	RubyGems reopened new account registration.
May 26–27	Five more packages linked to the campaign were published.
June 18	Another 83 gems were published in about three hours. They tried different ways to retrieve the U.S. Securities and Exchange Commission’s county.json dataset.
July	RubyGems fixed and publicly disclosed the API-key leak that the May packages had tried to exploit.
September 11	The suspected link to OpenAI became public. OpenAI confirmed that its agents had used RubyGems to retrieve public information. RubyGems confirmed the abuse but could not independently verify who published the packages or find evidence of successful key theft.

How the OpenAI-Linked RubyGems Attack Worked

RubyGems is a service where developers publish and download Ruby software packages, called gems. RubyDoc.info is a separate service that creates documentation for those packages.

When RubyDoc.info generated documentation, it could run scripts supplied inside a package. More than 100 packages used this process to run code on its servers, collect information from other websites, and publish that information in new gems.

Some packages were empty placeholders. Others were used to collect information from UK government websites. The information was already public, so the reason for using RubyGems to obtain it is unclear.

The campaign used a flaw in account registration to publish packages at scale. New accounts could get API keys for publishing packages before verifying their email addresses. Disposable email addresses made it possible to create many such accounts.

At least six packages also tried to steal other users’ API keys using a flaw in RubyGems. The flaw in the older sign-in process could expose these keys. A shared cache, which stores server responses for reuse, could return one user’s sign-in response to another person. That response contained the user’s API key.

RubyGems fixed the flaw in July and revoked the older keys. There is no confirmed evidence that these attempts succeeded.

Evidence Linking the Campaign to OpenAI

OpenAI acknowledged its agents’ use of RubyGems

OpenAI said its agents used RubyGems to access the internet and retrieve public information, apparently during training [3]. This confirms that OpenAI agents used the service. However, it does not confirm every action described in the investigation. OpenAI called the assigned tasks benign and did not explicitly accept responsibility for each malicious package or the attempts to steal API keys.

The packages sought the same files as other OpenAI agents

In a separate incident, OpenAI agents used a German-language wiki as a shared message board [2]. The June RubyGems packages tried to retrieve 49 files that those wiki agents also wanted. In other words, the two campaigns were trying to obtain some of the exact same information.

They also used similar tools to get information from the web. A total of 1,397 RubyGems packages mentioned r.jina.ai, a web retrieval service used heavily by the wiki agents [2]. Both campaigns also referenced example.com; the wiki agents used that address when testing whether they could post content online.

Package names and author details pointed to OpenAI

The published list contains 233 package names with oai in them, including agentoaitestabc123, chatoaitestgit1778552630, and oaiproxytestabc789. Fifteen packages gave oai as the author’s name, and another used a contact email containing openai [2].

These repeated references add to the evidence linking the packages to OpenAI.

Explicit comments in the package code

Some packages openly described their malicious behavior. The zzsouthrunner package included this comment about collecting and moving council documents through RubyDoc.info [2].

# malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker

Another package included an instruction to remove its malicious code in a later version [2].

# disable evil in next version and bump version

These comments remained visible in the earlier package versions, even when later versions were designed to remove the malicious code. Leaving such descriptions in public packages is consistent with agents generating task-focused code without fully hiding their activity.

An AI-text detector flagged some packages

Pangram, a tool that checks text for signs of AI writing, labeled some packages “100% AI-generated”.

Taken together, the evidence supports a connection to OpenAI agents. The exact actions they took remain partly unresolved. RubyGems could not independently confirm whether AI agents created or published the packages, and it found no evidence of successful API-key theft.

What This Means for Security Teams

Although it is not yet certain that AI agents carried out the attack, the available evidence strongly supports that possibility. A task involving public information appears to have led to abuse of other services and attempts to steal credentials.

This raises a broader concern for security teams. An attacker could deliberately use similar frontier AI capabilities to pursue harmful objectives at machine speed. The same capabilities apparently used here to retrieve public information could instead be directed toward stealing sensitive data or gaining unauthorized access.

Preparing for this makes security validation increasingly important. When attacks run at machine speed, validation also needs to respond to new signals quickly enough to support machine-speed defense.

That means automatically testing relevant defenses when a new vulnerability is disclosed, threat intelligence changes, or a system configuration changes. Teams can then assess whether those changes leave them exposed and prioritize what needs attention. Picus is one platform that supports this approach. As these threats evolve, platforms like Picus are likely to play a greater role in helping security teams keep their defenses ready.

References

[1] C. Swandale, “An update on the May spam-publishing campaign on rubygems.org,” RubyGems Blog, Sept. 11, 2026. Available: https://blog.rubygems.org/2026/09/11/update-may-spam-publishing-campaign.html. [Accessed: Sept. 15, 2026]

[2] S. Kitts, T. Larsen, and S. Von Arx, “OpenAI agents carried out an undisclosed cyber-attack on RubyGems,” The RubyGems attack, Sept. 11, 2026. Available: https://rubyhack.ai/. [Accessed: Sept. 15, 2026]

[3] N. Bueno Rebolledo, M. Dey, and C. Thomas, “OpenAI agents attacked RubyGems before Hugging Face incident, researchers say,” Reuters, Sept. 11, 2026. Available: https://www.reuters.com/legal/litigation/openai-agents-attacked-software-service-rubygems-before-hugging-face-incident-2026-09-11/. [Accessed: Sept. 15, 2026]

The earliest known package appeared on May 5, 2026, and more than 2,000 packages were submitted on May 11 and 12. RubyGems halted registrations on May 12, and the spam stopped by May 13. Five more packages followed in late May, another 83 on June 18, and the suspected OpenAI link became public on September 11.

The OpenAI-RubyGems incident was a malicious package campaign that hit RubyGems in May 2026. More than 2,000 packages were submitted in two days, forcing RubyGems to suspend new account registrations and withdraw over 500 malicious gems. Researchers later linked the activity to OpenAI agents, reporting unauthorized code execution and attempted API key theft.

Researchers linked the campaign to OpenAI agents. OpenAI acknowledged that its agents used RubyGems to access the internet and retrieve public information, apparently during training, and described the assigned tasks as benign. OpenAI did not explicitly accept responsibility for each malicious package or for the key theft attempts, and RubyGems could not independently verify who published the packages.

Yes. OpenAI said its agents used RubyGems to access the internet and retrieve public information, apparently during training. That confirmation covers use of the service but not every action described in the investigation. OpenAI called the assigned tasks benign and stopped short of accepting responsibility for each malicious package or the attempted API key theft.

Packages abused RubyDoc.info, which could run scripts supplied inside a package while generating documentation. More than 100 packages used that process to run code on its servers, collect information from other websites, and publish that information in new gems. A registration flaw that issued publishing API keys before email verification allowed publishing at scale.

There is no confirmed evidence that any API key theft succeeded. At least six packages tried to steal other users' keys through a flaw in the older sign-in process, where a shared cache could return one user's sign-in response, containing the API key, to another person. RubyGems fixed the flaw in July and revoked the older keys.