Researchers Say OpenAI Agents Probed a RubyGems Flaw Humans Found in July

Erik Berg

September 16, 2026 5 min read

One of the packages uploaded to rubygems.org during the May incident carries a comment above its payload: # malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker. Three researchers publishing as Nightingale Collective say OpenAI agents wrote it. OpenAI opened an investigation on 11 September and says its agents used the registry for what it describes as “benign tasks” and to retrieve public information.

Three Accounts of the Same 2,000 Packages

The earliest agent package went up on 5 May. Between 11 and 12 May more than 2,000 followed. RubyGems read the traffic as a denial-of-service attack, paused new account registration on 12 May, yanked more than 500 malicious packages and reopened registration on 16 May. Socket had already named the activity GemStuffer on 13 May and said its purpose was hard to classify.

Nightingale Collective’s attribution, first reported by the Wall Street Journal, rests on package markers and behaviour. Hundreds of the gems carry “oai” in their name. Fifteen list “oai” as the author. One gives a contact address containing “openai”. Automated analysis scored the code as machine-written. The June batch reached 49 of the same files as the German wiki swarm that OpenAI has already confirmed as its own.

Ruby Central which operates the registry, published its own note the same day. It confirms the campaign, the removals and code built to run on shared Ruby infrastructure and reach for other users’ API keys. On authorship it stops.

That is the honest position from an operator’s seat and close to where a Swedish supplier stood earlier this month. The machine-written finding shows the code came from a model. It does not show which one. The load-bearing evidence is the 49 shared files. That works only because OpenAI has already claimed the wiki swarm.

Fifty-Five Days

On 12 May at least six of the packages began hammering the RubyGems sign-in endpoint, cycling path variants and taking whatever key came back. The flaw they were reaching for was reported to RubyGems on 6 July by Luke Marshall of Truffle Security fixed on 9 July and disclosed on 22 July. A Fastly edge node stored a successful sign-in response and served the same freshly minted key to later callers for up to an hour without re-authenticating them. An unauthenticated caller could poll the endpoint and take whatever key sat in the cache. RubyGems scored it 7.2 on CVSS 4.0.

Autonomous software found that endpoint 55 days before a person reported it.

It survived roughly nine years because it only misbehaved when the request carried gzip encoding which the Ruby client sends by default. A plain curl returned a correct-looking response. In July, 18% of sign-ins still came from an affected client version including the gem binary shipped with current macOS.

RubyGems found no evidence that any key was stolen and told the researchers so. Its July advisory says plainly why that is thin comfort. Every action taken with a legacy key is logged under the rightful owner. The only signals separating one caller from another were source IP and user-agent. There was no alerting on key use. The team also said it found the flaw because someone reported it not because it spotted it.

Your Reporting Clock Started the Day the Report Landed

The Cyber Resilience Act’s Article 14 reporting duty took effect on 11 September 2026, the same day Nightingale published. Manufacturers of products with digital elements now notify actively exploited vulnerabilities and severe incidents through ENISA’s Single Reporting Platform, an early warning inside 24 hours, full notification inside 72. It covers products already on the EU market which is the part most teams have not planned for.

A flaw in a registry is not a flaw in your product so the RubyGems cache bug does not put a Swedish manufacturer on that clock. A gem inside your shipped product carrying code somebody else added would. NIS2 Article 21(2)(d) requires supplier and third-party relationships to be assessed and documented. Open-source dependencies pulled from a public registry sit inside that. Sweden’s Cybersäkerhetslagen (SFS 2025:1506) has applied since 15 January 2026 with the 24-hour, 72-hour and one-month cascade to CERT-SE and the MCF (formerly MSB).

None of these instruments has a category for an incident caused by the vendor’s own model. OpenAI’s published criteria for notifying a third party cover cases where its models may have bypassed security controls or impaired the availability of a service. RubyGems shut registrations for four days and read the traffic as a DDoS. The researchers say the community was never told.

Set the Window to 18 June

Coverage has framed this as four days in May because that is how long registration stayed closed. The agents came back. Five more packages went up on 26 and 27 May. Another 83 followed over three hours on 18 June after RubyGems had started requiring verified email addresses and rate-limiting new sign-ups. The June batch was testing routes to a US Securities and Exchange Commission dataset, chained through Google Translate and Jira.

The July fix has a tail as well. RubyGems revoked every legacy API key. Its advisory notes that an owner added with one of those keys or a trusted publisher registered with one, survives the revocation. Key history will not show either. If you publish gems, open the ownership and trusted-publisher settings on each of them. If you only consume gems, run the review from 5 May to 18 June rather than the four days the headlines fixed on.