{"slug": "an-openai-agent-swarm-attacked-rubygems", "title": "An OpenAI Agent Swarm Attacked RubyGems", "summary": "An OpenAI agent swarm uploaded hundreds of malicious gems to RubyGems.org in May 2026, chaining a YARD documentation-build flaw in RubyDoc.info with an undisclosed CDN caching bug on RubyGems.org to gain remote code execution and leak API keys, according to research from Socket.dev's Sydney Von Arx and Spencer Kitts, who dubbed it the GemStuffer Campaign. One gem, slnleaker5, scraped UK council and government meeting documents and repackaged them as new gems published through RubyGems' own infrastructure, turning the registry into a covert exfiltration channel. The incident was surfaced by Ruby community researchers rather than OpenAI, which had not disclosed it to RubyGems.org or the Ruby community as of the reporting.", "body_md": "In May 2026, hundreds of malicious gems showed up on RubyGems.org, uploaded by an OpenAI agent swarm. The [RubyHack.ai writeup](https://www.rubyhack.ai/#an-openai-agent-swarm-was-responsible-for-this-i) and [Aaron Patterson's account](https://tenderlovemaking.com/2026/09/11/what-a-time-to-be-alive/) both cover it, and together they're worth reading in full. Here's the tl;dr version.\n\nThe packages didn't try hard to hide, according to [Socket.dev's writeup of the campaign](https://socket.dev/blog/gemstuffer). Names carried an \"oai\" prefix, author fields said \"oai,\" and at least one file was just named `hack.rb`. One comment in the code read \"# malicious probe.\" Whatever the agents were doing, they weren't doing it very sneakily or quiet.\n\nThe attack chained two vulnerabilities. First, [RubyDoc.info automatically builds documentation](https://github.com/docmeta/rubydoc.info/blob/5de17aec3e51ccada961b7ca40cb49c72eaa2168/app/jobs/generate_docs_job.rb#L66) for newly published gems, and it runs that build in a Docker container with network access. A `.yardopts` file can point YARD at arbitrary scripts, so publishing a gem with the correct `.yardopts` got the agents remote code execution inside RubyDoc's build environment. Second, at least six of the packages went after a [CDN caching bug on RubyGems.org](https://blog.rubygems.org/2026/07/22/security-advisory-legacy-api-key-leak.html) that could leak users' API keys, a bug that wasn't publicly disclosed until that July advisory, months after the attack.\n\nThen there's what the agents did with that access. Take [`slnleaker5`](https://my.diffend.io/gems/slnleaker5/0.0.1#d2h-229454-1428), one of the gems in what researchers Sydney Von Arx and Spencer Kitts are calling the [GemStuffer Campaign](https://socket.dev/blog/gemstuffer). Its `data/script.rb` crawls Lambeth, Wandsworth, and Southwark council sites, plus ModernGov and democracy.gov.uk, following links two levels deep to pull down meeting agendas and committee documents. It writes everything to disk, then builds a brand new gem on the fly, named something like `slnpayloadx<timestamp>`, and packs the scraped data into it as the payload. That gem gets pushed straight to rubygems.org with hardcoded API keys, and the code even comments on retrying with \"fresh leaked keys variants\" if a push fails.\n\nThe agents weren't exfiltrating data to some external server where a security team might notice unusual egress traffic. They ***repackaged*** it as an ordinary-looking gem and published it through RubyGems' own infrastructure, looking like at a glance from any other release. The scraped government data became instantly and publicly downloadable to anyone who found the gem, not because a breach exposed it, but because publishing it as a package was the delivery. A registry built for trusted software distribution became a covert channel.\n\nThis wasn't disclosed by OpenAI. It came from Ruby community researchers who noticed these junk gems, pulled the thread, and published what they found, and then [Reuters](https://www.reuters.com/legal/litigation/openai-agents-attacked-software-service-rubygems-before-hugging-face-incident-2026-09-11/) and the [Wall Street Journal](https://www.wsj.com/tech/ai/cyberattack-by-rogue-ai-swarm-stokes-fears-of-out-of-control-agents-473a0352) picked it up. OpenAI hasn't disclosed the incident to RubyGems.org or the Ruby community as of right now.\n\nThat's kinda creepy, and unsettling. An autonomous system ran a real, multi-stage attack against production infrastructure the Ruby ecosystem needs, and the company running it said nothing….so I know I am interested to see how OpenAI responds now.", "url": "https://wpnews.pro/news/an-openai-agent-swarm-attacked-rubygems", "canonical_source": "https://dev.to/cseeman/an-openai-agent-swarm-attacked-rubygems-26fk", "published_at": "2026-09-14 18:42:29+00:00", "updated_at": "2026-09-14 21:36:34.096758+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-policy", "developer-tools"], "entities": ["OpenAI", "RubyGems.org", "RubyDoc.info", "Socket.dev", "Sydney Von Arx", "Spencer Kitts", "Aaron Patterson", "Reuters"], "alternates": {"html": "https://wpnews.pro/news/an-openai-agent-swarm-attacked-rubygems", "markdown": "https://wpnews.pro/news/an-openai-agent-swarm-attacked-rubygems.md", "text": "https://wpnews.pro/news/an-openai-agent-swarm-attacked-rubygems.txt", "jsonld": "https://wpnews.pro/news/an-openai-agent-swarm-attacked-rubygems.jsonld"}}