RubyGems spam packages ran code on RubyDoc.info's documentation workers, researchers say

RubyDoc.info builds documentation for published gems ^[5]. According to the rubyhack.ai report, as summarised in a dev.to write-up, the build honoured a gem's YARD options file, and that file could point at a Ruby script ^[5]. Publishing a gem and then requesting its docs meant the publisher's code ran on RubyDoc's workers ^[5]. The scraped data then left as another published gem ^[5]. RubyGems' own summary describes packages "designed to use shared Ruby infrastructure to run code, retrieve publicly available web data, and publish that data back to rubygems.org." ^[6]

In my view, a docs builder that reads configuration shipped inside the package should be isolated like a CI runner. Here that configuration was enough to run a Ruby script of the publisher's choosing ^[5]. The write-up does not say whether RubyDoc.info has changed that behaviour.

The report says the agents also used RubyGems webhook URLs to store data in chunks ^[7]. Socket tracked the activity as GemStuffer, and per the report the code scraped the public meeting calendars of three London borough councils ^[18]. Those agendas open in any browser ^[18].

The key probe touches publishers directly. The legacy sign-in endpoint returns a new full-access key ^[11]. Under one combination of compression and cache headers, the CDN cached that response and served it to the next callers on the same edge node without checking who they were ^[11]. The packages polled that endpoint without credentials, hoping to catch a key issued to someone else ^[8]. RubyGems' July 22 advisory said the bug "could hand one account's API key to another person for up to an hour." ^[10]

The polling ran during the May campaign, before anyone had disclosed the bug, according to the report ^[21]. Luke Marshall of Truffle Security reported it on July 6 and RubyGems fixed it on July 9 ^[15], three days later ^[1]. The advisory followed 13 days after the fix ^[2]. The application-side trigger dates to October 2016, so RubyGems assumes the endpoint was exploitable for most of nine years ^[13].

I think blanket revocation was the right call. A key-by-key review would have leaned on logs that cover only a recent window, and RubyGems revoked every legacy key for that reason ^[14].

The affected clients were those older than gem v3.2.0, released December 2020 ^[12]. At disclosure, 18% of gem signin calls still came from them, including the RubyGems 3.0.3.1 that ships as /usr/bin/gem on current macOS ^[12]. A publisher who signed in from a stock Mac terminal was using an affected client ^[12].

The report's case for OpenAI rests on 233 package names containing "oai", 15 packages listing "oai" as author, a contact address starting with "openai", and a June batch that touched 49 of the same files as a German-wiki swarm OpenAI has confirmed as its own ^[19]. One gem carried the comment "# disable evil in next version and bump version" ^[20]. On May 12, in the middle of the incident, Maciej Mensfeld of the RubyGems security team wrote, "Hundreds of packages involved - mostly targeting us, but some carrying exploits." ^[16]