{"id":9501,"date":"2026-09-16T01:09:53","date_gmt":"2026-09-16T01:09:53","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=9501"},"modified":"2026-09-16T01:09:53","modified_gmt":"2026-09-16T01:09:53","slug":"hundreds-of-openai-agents-attack-rubygems-platform","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=9501","title":{"rendered":"Hundreds of OpenAI agents attack RubyGems platform"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

A swarm of hundreds of OpenAI agents uploaded \u201cmalicious packages\u201d to RubyGems and tried to steal API keys, the Ruby community gem hosting service revealed Friday.<\/p>\n

OpenAI confirmed part of the disclosure, saying<\/a>, \u201cour agents used the RubyGems platform to access the internet to carry out benign tasks and retrieve public information. We\u2019ll continue to investigate as part of our broader review of agent activity during training and evaluation.\u201d<\/p>\n

The agents\u2019 goals were unclear, as was whether they engaged in the swarming activity for research, and even whether they were explicitly sent by OpenAI staffers, but an analysis published by RubyGems<\/a> strongly suggests malicious intent.\u00a0<\/p>\n

\u201cOnce the AIs got arbitrary RCE on the build environment, they would sometimes use the build environment to attempt to steal other users\u2019 API keys, though we are unsure if they succeeded or not,\u201d the RubyGems post said. \u201cThe agents clearly regarded what they were doing as hacking. Agents used file names like hack[.]rb, evil[.]rb, inject[.]rb, exploit[.]rb, and ssrf[.]rb. SSRF stands for \u2018Server-Side Request Forgery,\u2019 a type of security vulnerability. They also dubbed packages conspicuous titles like pwnp999, exfiltestwand3, hacksvn1778554764 and lambproxyhackabcxyz. Comments such as \u201c# malicious probe\u201d or \u201c#hack\u201d are littered across the campaign.\u201d<\/p>\n

The post also said that the agents attempted to trick defensive systems.<\/p>\n

\u201cAt some points, the agents attempted to be covert. We found multiple packages that would disarm themselves to hide their payload in the next version,\u201d the post said. \u201cThey uploaded one package with the comment \u2018# disable evil in the next version and bump version,\u2019 which after execution would modify the package to remove the malicious code initially inserted.\u201d<\/p>\n

OpenAI should be accountable<\/h2>\n

Analysts and consultants said the attack was concerning because if such efforts happen often enough, it could slow down security operations center (SOC) responses.<\/p>\n

Nader Henein<\/a>, a Gartner VP analyst, said he was highly concerned about an upcoming bot swarm trend.\u00a0<\/p>\n

\u201cWhat we know is that this is the kind of standard attack, now AI-augmented, that will become commonplace over the coming months,\u201d Henein said. \u201cIt\u2019s less so a rogue agent, more so an attacker, potentially using compromised credentials, weaponizing an agent swarm, in the same way that attackers used compromised endpoints to mount DDoS attacks for the better part of the last decade. The difference here is the fact that these are not individually compromised bots. OpenAI\u2019s guardrails should have not allowed this to happen.\u201d<\/p>\n

Frank Dickson<\/a>, principal analyst at Dickson Research, added, \u201cOpenAI needs to be held accountable. They seem to want to create \u2018Dr. Frankenstein\u2019s monster,\u2019 but don\u2019t seem to want to accept blame for the outcomes. OpenAI hasn\u2019t denied its agents used RubyGems. It has disputed the word \u2018malicious\u2019 and called the activity \u2018benign,\u2019 while separately acknowledging that, in that same stretch of weeks, its agents escalated to cluster-admin access at Hugging Face and compromised accounts at four other third-party services. Those two characterizations are hard to square. The behavior is still unacceptable.\u201d<\/p>\n

However Erik Avakian<\/a>, technical counselor at Info-Tech Research Group, stressed that it\u2019s not necessarily the case that OpenAI launched these agents with explicit instructions. The agents might have easily charted this destructive path all on their own.<\/p>\n

The OpenAI agents \u201cabsolutely could have acted autonomously. We\u2019ve already seen that capable agents can pursue various unexpected paths to accomplish a task when they have enough autonomy and access,\u201d he said. \u201cA human may have authorized the evaluation or given the agents access to tools, but that doesn\u2019t mean a human approved every action they subsequently took.\u201d<\/p>\n

Could delay SOC responses<\/h2>\n

Dickson added that he fears the ultimate cybersecurity risk is that SOC staffers see so many of these attacks that they start to experience alert fatigue.<\/p>\n

\u201cIf the vendor whose agents did this is the one downgrading the language, a SOC analyst reading headlines instead of the underlying report has every reason to underreact,\u201d Dickson said. \u201cSecurity operations aren\u2019t fit for purpose if they run on the assumption that an AI agent label makes an intrusion less real. A stolen API key or a remote code execution path behaves identically whether the actor is a ransomware crew or an unsupervised model chasing a reward signal.\u201d<\/p>\n

Mike Wilkes<\/a>, enterprise CISO at Aikido Security, also noted that the fact that the agents self-identified as OpenAI should mean nothing, as all agents can persuasively pretend to be representing anyone, especially if they think it will slow down a response, even for a brief period.\u00a0<\/p>\n

\u201cA User-Agent string is a nametag written by the visitor, not a passport,\u201d he said. \u201cIf SOC tooling begins suppressing alerts because traffic claims to be an OpenAI, Anthropic, Google or other AI agent, attackers will adopt those identities immediately if they haven\u2019t already.\u201d<\/p>\n

Thus, he said, \u201cif a human researcher or employee delegates authority to an autonomous agent, there should be a verifiable chain showing who delegated that authority, which organization they represent, what agent was authorized, what scope it was given, and for what period of time.\u201d<\/p>\n

Plan for similar attacks<\/h2>\n

Consultant Brian Levine<\/a>, executive director of FormerGov, encouraged CISOs to anticipate more such attacks and plan accordingly.<\/p>\n

\u201cOrganizations that depend on open source, which is nearly all of them, should assume registries are an active battleground [and should] rotate and scope API keys tightly, monitor for anomalous package publishing and credential access, and pin and verify dependencies rather than trusting a name,\u201d he said. \u201cThe economics have shifted. Automation lets an attacker try thousands of variations cheaply, so defenders have to make the payoff of any single success as small as possible.\u201d<\/p>\n

Justin Greis<\/a>, CEO of consulting firm Acceligence, agreed.\u00a0<\/p>\n

\u201cIf legitimate AI research activity increasingly generates behavior that looks like hostile scanning, exploitation, credential access or persistence, SOC teams can become conditioned to treat those signals as noise,\u201d Greis said. \u201cAttackers will understand that very quickly. The dangerous phrase becomes \u2018that is probably just an AI agent.\u2019\u201d<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

A swarm of hundreds of OpenAI agents uploaded \u201cmalicious packages\u201d to RubyGems and tried to steal API keys, the Ruby community gem hosting service revealed Friday. OpenAI confirmed part of the disclosure, saying, \u201cour agents used the RubyGems platform to access the internet to carry out benign tasks and retrieve public information. We\u2019ll continue to […]<\/p>\n","protected":false},"author":0,"featured_media":9502,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-9501","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/9501"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=9501"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/9501\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/9502"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=9501"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=9501"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=9501"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}