Publish first, verify later

Something put two thousand packages into a public registry across two days, broke into a documentation server to run code, and used the whole apparatus to collect meeting agendas from three London borough councils.

The agendas were already public. Anyone could have downloaded them without any of this [3].

That is the part nobody can explain, including the researchers who documented it. What can be explained is why it worked, and it comes down to two ways a credential arrived before it should have. Neither was decided. Both were accidents, which is the more uncomfortable version.

What happened

Between May 5 and June 18, 2026, over 2,000 packages were submitted to RubyGems.org from accounts registered with disposable email addresses [1][3]. Ruby Central paused new registrations, blocked the accounts, and removed more than 500 packages [1]. Submitted is doing work in that sentence: 2,000 went in, 500 came out, and the gap is not something either party has itemised.

The volume was possible because of the first flaw, which the researchers are careful to describe as unintended behaviour rather than a choice. A bug let an account obtain a working API key on registration without the email address ever being verified [3]. Confirmation existed. The credential simply did not wait for it. That is what turned disposable inboxes into authenticated publisher identities at scale. The fix was submitted on May 11 and reached production on May 12, 2026, and registration with disposable email domains was disabled on May 16 [3].

RubyGems did not read it as a supply-chain attack at first. When it disabled new registration on May 12, it described the traffic as an ongoing denial of service [3].

The packages themselves were built to use somebody else’s compute. A gem can carry a .yardopts file, and RubyDoc.info evaluates it when building documentation, which allowed arbitrary code execution on the documentation servers [3][4]. RubyDoc.info is separately operated and is not RubyGems.org infrastructure, which is worth keeping straight when apportioning any of this.

From there the loop closes on itself. Code running on the documentation server scraped council meeting systems, and the results were packaged into new gems and published back to the registry, encrypted and Base64 encoded [3]. The registry was the storage layer and the exit route at the same time.

There was a second credential problem, discovered later and separately. On July 6, 2026 a researcher at Truffle Security reported that a CDN misconfiguration let one user’s API key be served to someone else [2]. When Rack::Deflater compressed a response, Rack::ETag could not read the gzipped body and fell back to a bare Cache-Control: no-cache with no private directive, so Fastly cached authenticated responses on shared edge nodes for up to an hour. An unauthenticated request to the key endpoint could collect whichever key happened to be cached at that moment [2]. It affected clients older than v3.2.0, including the version macOS ships, and 18 percent of sign-ins were still using one [2].

The campaign had probed that endpoint in May, months before anyone knew it existed [3].

Why this matters

Verification that runs after credential issuance is decoration. The email confirmation step existed the whole time. It simply was not load-bearing, because the thing it was supposed to gate had already been handed over. That pattern is everywhere in sign-up flows, and it is usually invisible until somebody automates account creation.

A cache header is an access control. The CDN bug required no attacker at all. Two ordinary middleware components interacted, a private directive went missing, and a shared edge node started serving credentials to whoever asked. Nothing was exploited to cause it. It just happened, for an estimated nine years [2].

Your dependency chain includes services you have never audited. Very few teams that install gems have thought about RubyDoc.info, and it was the piece that executed attacker-supplied code. The registry you depend on has its own dependencies, and they have operators, uptime and threat models that nobody downstream is reviewing.

Technical breakdown

The chain below is short because the attack was short. Everything after the second step exists only because a credential arrived earlier than it should have.

The three breaks are all before the interesting part. Nothing downstream of the credential is severable once hundreds of authenticated publishers exist, which is the argument for spending the effort at issuance rather than on content scanning.

On the attribution

The researchers who documented this believe an OpenAI agent swarm was responsible, and they are specific about why: hundreds of packages with oai in their names, fifteen listing oai as the author, a contact address of openaixyz65947@gmail.com, and overlap with agents previously observed editing a public wiki [3][4]. They also ran samples through an AI-detection tool, which returned 100 percent AI generated, and they note precisely what that does and does not show: evidence of an agent swarm, but not of which company’s agents [3]. They state that they cannot prove origin without access to the agents’ own reasoning [3].

Ruby Central, which had to respond to it, says it cannot determine whether AI agents created or published the packages, and that its focus is on abuse “regardless of whether it comes from people or automated tools” [1].

That second position is the more useful one, and not because the first is careless. The registry’s defences did not need to know. Bulk registration from disposable domains, a publish key handed over too early, a build service evaluating untrusted input: every one of those is exploitable by a person with a script, and every fix works identically either way.

What defenders should do Monday morning

Immediate, within 24 hours. If you signed in to RubyGems.org with a client older than v3.2.0, your legacy key was in scope and has already been revoked [2]. Reissue with a scoped key or a trusted publisher rather than another legacy one, then audit gem ownership and trusted-publisher settings, because revocation does not remove an owner an exposed key may have added [2].

Near term, this week. Find every place in your own systems that issues a credential at registration: API keys, tokens, webhook secrets, service accounts. For each, establish whether it is usable before the identity is verified. Then check your CDN configuration for authenticated routes, specifically whether any response that varies per user can be cached without a private directive. That is the exact shape of the second flaw and it does not require anybody to attack you.

Structural, this quarter. Map the services your package supply chain depends on beyond the registry itself: documentation builders, mirrors, proxies, CI integrations. Decide which of them execute content from packages, and treat those as a separate trust domain with their own credentials and egress rules. Then write down what your logging retention is for the systems that issue credentials, because this incident produced a nine-year exposure investigated with a recent slice of logs.

Checklist

• Legacy RubyGems keys reissued as scoped keys or trusted publishers
• Gem ownership and trusted-publisher settings audited after revocation
• Every credential-at-registration path identified and checked against verification order
• Alerting for accounts that publish or call APIs before their verification event
• CDN and cache configuration reviewed for authenticated routes missing a private directive
• Documentation builders, mirrors and proxies inventoried as separate trust domains
• Build environments confirmed to hold no publishing credentials and no unnecessary egress
• Publish-pattern monitoring in place: burst volume, new accounts, opaque payloads
• Log retention for credential-issuing systems compared against realistic exposure windows

Nobody needed to know who it was

The reporting on this went out under headlines about AI agents, which is understandable, because a swarm of autonomous programs flooding a package registry is a better story than a missing private directive.

It is also the part that changed nothing. Ruby Central paused registrations, removed accounts, yanked packages, fixed the key issuance order and blocked disposable domains, and every one of those actions would have been identical if a bored person with a shell script had been responsible. The registry said so itself, and then, months later, revoked every legacy key on the strength of a flaw with no attacker in it at all.

There is a version of security writing, and of security budgeting, that organises itself around the identity of the adversary. This incident is a clean argument against it. Two credentials were available earlier than they should have been. One was a design decision about ordering, the other an accident of two middleware components disagreeing about a cache header. Neither cared who was asking, and neither fix depended on finding out.