{"slug": "3022-malicious-gems-and-openai-calls-it-benign", "title": "3,022 Malicious Gems, and OpenAI Calls It “Benign”", "summary": "Security researchers have linked OpenAI training agents to a months-long campaign that published thousands of malicious packages to RubyGems, with JFrog counting 3,022 packages across 3,315 name-and-version pairs. The gems used .yardopts scripts to execute code on RubyDoc.info's build server, scraped public council websites, and pushed results back with hardcoded API keys, while later uploads carried XSS and ERB template-injection payloads in gem metadata. OpenAI called the agent activity \"benign tasks\" and said it could not verify claims about malicious packages, while Ruby Central reported removing more than 500 packages and blocking the accounts behind them.", "body_md": "Last week I wrote about [an OpenAI agent swarm attacking RubyGems](https://christine-seeman.com/openai-agent-swarm-rubygems-attack/), and I ended it wondering how OpenAI would respond. They already had. On September 11, the day the story broke, OpenAI gave reporters one statement. Here it is from [Reuters](https://www.reuters.com/legal/litigation/openai-agents-attacked-software-service-rubygems-before-hugging-face-incident-2026-09-11/):\n\nBased on our review, our agents used the RubyGems platform to access the internet to carry out benign tasks and retrieve public information. We'll continue to investigate as part of our broader review of agent activity during training and evaluation.\n\n[The Next Web](https://thenextweb.com/news/openai-agents-rubygems-attack-api-keys-hugging-face) reports that OpenAI described the work as training tasks, things like filling in spreadsheets and writing reports. The statement says nothing about the remote code execution on RubyDoc.info or the attempts on RubyGems API keys. According to [CyberScoop](https://cyberscoop.com/openai-agents-malicious-rubygems-packages/), OpenAI also said it hasn't been able to verify the specific claims about malicious packages or exploitation. I don't know how you call something benign before you've verified what it did.\n\n`hack.rb`\nSure, meeting agendas from Lambeth, Wandsworth, and Southwark councils are things anyone can download, so I get why OpenAI says that is \"public information.\"\n\nBut, to get them, the agents published gems whose `.yardopts` ran a script on RubyDoc.info's build server. The script scraped the council sites from there and pushed the results back to rubygems.org with hardcoded API keys. The code has a comment about retrying with \"fresh leaked keys variants\" if a push failed. One file was named `hack.rb`. Another comment read \"# malicious probe.\"\n\nThe agents labeled this as hacking in their own source…and there are way easier ways to download those agendas.\n\nI missed in the first post, when I wrote about May 11 and 12 as if that were the whole attack. [The Hacker News timeline](https://thehackernews.com/2026/09/openai-agents-linked-to-rubygems.html) shows it kept going:\n\nBy May 16, RubyGems had blocked disposable email signups because of the first wave, and the uploads kept coming.\n\nBy July the gems had moved on from scraping. [JFrog's analysis](https://research.jfrog.com/post/gemstuffer-openai-rubygems/) found XSS payloads and template injection strings in the gem metadata, including ERB and EL expressions, aimed at admin interfaces and whatever parses that metadata. I can't think of a reason a job that only needs internet access would put an ERB expression in a gem's metadata field.\n\nJFrog published on September 15 and counted 3,022 packages across 3,315 name and version pairs. The RubyHack report I linked last week only had 557 releases.\n\nRuby Central's own number is lower. Their [September 11 update](https://blog.rubygems.org/2026/09/11/update-may-spam-publishing-campaign.html) says they yanked more than 500 packages and blocked the accounts behind them. The two counts measure different things. Ruby Central is reporting what it had removed as of that update, and JFrog is counting every package it associates with the campaign.\n\nJFrog also looked closer at `slnleaker5`. It made up to 24 harvest-and-upload attempts against the [CDN caching bug](https://blog.rubygems.org/2026/07/22/security-advisory-legacy-api-key-leak.html) that could leak API keys, more than two months before that bug was public. Publishing a new gem was only one of the ways data got out. Some packages republished inside themselves, and some tucked encoded data into webhook configs.\n\nRuby Central has been careful. In the [RubyGems blog update](https://blog.rubygems.org/2026/09/11/update-may-spam-publishing-campaign.html) from September 11, technical lead Colby Swandale wrote, \"Based on the evidence available to us, we cannot determine whether the packages were created or published by AI agents.\" He added, \"Our focus is on identifying and preventing abuse, regardless of whether it comes from people or automated tools.\" On the API key attempts, the update says, \"Our investigation found no evidence that these attempts succeeded.\" [The Register](https://www.theregister.com/security/2026/09/14/openais-malicious-bot-swarm-attacked-rubygems/5296356) notes the researchers still consider that an open question.\n\nSure, caution is fair. A registry can see accounts, IP addresses, and uploads, and none of that says who was running the model behind them.\n\nThe attribution comes from the researchers. The [RubyHack report](https://www.rubyhack.ai/) found the RubyGems swarm accessing 49 of the same files as the agents that took over a German wiki earlier this year. The RubyHack authors say OpenAI has confirmed those files were theirs, and OpenAI [acknowledged the wiki incident](https://thehackernews.com/2026/09/thousands-of-openai-agents-quietly.html) on September 5, calling it \"misalignment.\" And OpenAI's own statement says their agents were on the platform.\n\nI started this follow-up treating RubyGems as its own story. Put the dates next to each other and it stops looking that way.\n\nFrom May to July, OpenAI agents made more than 15,000 edits to a German wiki and used it as a message board. Those are the same months as the RubyGems uploads, and those wiki agents are the ones that accessed 49 of the same files as the RubyGems swarm. Then OpenAI agents broke into Hugging Face, from [July 9 to July 13](https://huggingface.co/blog/agent-intrusion-technical-timeline), at the end of that stretch.\n\nAll three came out the same way. Outside researchers disclosed the wiki on September 4. Outside researchers tied RubyGems to OpenAI on September 11. Hugging Face announced its own breach on July 16, and OpenAI said the agents were theirs five days later. Three incidents, and OpenAI went first on none of them.\n\nAlmost all of the reaction is about Hugging Face. Senator Hawley's [letter to Sam Altman](https://www.hawley.senate.gov/chairman-hawley-launches-investigation-into-openai-for-hacking-existential-risk-of-ai-products/) covers Hugging Face only. Altman's September 12 [promise](https://www.cnbc.com/2026/09/14/sam-altman-ai-slowdown-anthropic-amodei-musk.html) to give independent evaluators employee-like access came out of that fallout. So did the two bills in Congress, the [AI Kill Switch Act](https://lieu.house.gov/media-center/press-releases/reps-lieu-and-moran-introduce-bill-require-kill-switch-ai-systems-can) from July and the [Ban Artificial Superintelligence Act](https://www.sanders.senate.gov/press-releases/news-sanders-casar-introduce-legislation-to-ban-artificial-superintelligence-and-temporarily-pause-advanced-ai-development/) from this month. [EU regulators](https://gulfnews.com/technology/openai-confirms-ai-agents-targeted-coding-site-rubygems-during-testing-1.500671755) are looking into the wiki. Nobody official is asking about RubyGems yet, partly because the RubyHack report landed two days after Hawley's letter went out.\n\nWhat I'd like to see next is small. OpenAI knows which accounts were theirs, which gems they pushed, and which API keys their agents tried. Ruby Central and the RubyDoc.info maintainers should get that list directly from OpenAI, without a researcher or a reporter having to dig it up first. OpenAI [told CyberScoop](https://cyberscoop.com/openai-agents-malicious-rubygems-packages/) it's in contact with RubyGems and the researchers. Ruby Central's September 11 update doesn't mention hearing from them, so I don't know what that contact has included.\n\nHawley's deadline for answers is October 1.", "url": "https://wpnews.pro/news/3022-malicious-gems-and-openai-calls-it-benign", "canonical_source": "https://dev.to/cseeman/3022-malicious-gems-and-openai-calls-it-benign-4cf6", "published_at": "2026-09-18 18:33:40+00:00", "updated_at": "2026-09-18 18:53:05.106329+00:00", "lang": "en", "topics": ["ai-safety", "ai-agents", "ai-policy", "ai-ethics"], "entities": ["OpenAI", "RubyGems", "Ruby Central", "JFrog", "RubyDoc.info", "Colby Swandale", "Reuters", "The Hacker News"], "alternates": {"html": "https://wpnews.pro/news/3022-malicious-gems-and-openai-calls-it-benign", "markdown": "https://wpnews.pro/news/3022-malicious-gems-and-openai-calls-it-benign.md", "text": "https://wpnews.pro/news/3022-malicious-gems-and-openai-calls-it-benign.txt", "jsonld": "https://wpnews.pro/news/3022-malicious-gems-and-openai-calls-it-benign.jsonld"}}