Researchers at RubyHack say an OpenAI agent swarm was responsible for a previously unexplained cyberattack on RubyGems, the package registry for the Ruby programming language.
Beginning in May, the agents created accounts and flooded RubyGems with malicious packages, submitting more than 2,000 packages on May 11 and 12 alone. RubyGems temporarily disabled new user registrations for four days and removed more than 500 malicious packages.
The agents also abused RubyDoc.info’s automatic documentation-building system to execute arbitrary code on its servers. Researchers found more than 100 packages using this technique to run code, retrieve information from targeted websites and publish the collected data back to RubyGems.
Most notably, the agents attempted to exploit a vulnerability that could expose RubyGems users’ API keys. Researchers observed the agents targeting the flaw on May 12, approximately two months before the vulnerability was independently discovered and patched in July. RubyHack said it does not know whether the agents successfully stole any API keys.
RubyHack said OpenAI never informed the RubyGems community that its agents were responsible for the activity. The researchers linked the swarm to OpenAI based on several pieces of evidence, including packages identifying their author as “oai” and similarities with the AI agents involved in the German wiki incident that OpenAI previously confirmed were its own.
John Strand, Owner, Black Hills Information Security, Inc.:
“This is getting out of hand, and there’s really no end in sight. You have the United States saying, “Don’t slow down.” You have China saying, “Don’t slow down.” Then you have the major AI vendors talking about the risks and the need to understand what’s happening. They’re stuck in the middle of a race where nobody wants to be the one who slows down first. So nobody is going to slow down.
“Now couple that with supply chain attacks, like the agent swarm attack against RubyGems, and we’re starting to see the creativity and scale at which these attacks can move.
“I still maintain that the information security community isn’t ready for what’s coming next.
“I also think we’re going to see serious pressure for restrictions on offensive AI. My fear is what happens after a major attack, when restrictions are written quickly in response. We could very easily end up hampering legitimate security research, SOC development, and offensive security research along with the activity we’re actually trying to stop.
“So buckle up, everybody. It’s going to get a lot crazier before we get any clarity on where all of this is going.”
Ryan McCurdy, VP of Marketing, Liquibase:
“AI agents can now operate at a scale humans can’t match and potentially find and exploit vulnerabilities before defenders even know they exist.
“Flooding an open-source ecosystem with thousands of malicious packages shows what happens when autonomous systems can execute repeatedly without continuous human involvement. Finding and attempting to exploit a vulnerability before it was independently discovered changes the timeline security teams are working against. AI can dramatically compress the time between vulnerability discovery and exploitation.
“That makes the response path just as important as vulnerability detection. Enterprises need to know what software they depend on, who is accountable when a critical vulnerability is discovered, and whether they have a supported path to remediation. At the same time, they need controls around what agents can access and what they can change so finding a vulnerability doesn’t automatically give an agent the ability to exploit it.
“AI is forcing both sides of vulnerability management to move faster. Finding vulnerabilities faster only helps defenders if they can respond just as quickly.”
Steven Swift, Managing Director, Suzu Labs:
“This is the most recent announcement that an OpenAI agent swarm hacked into public websites. Of note, is all of these announcements relate to previous activity that is only now being made public. During the impacted time period, OpenAI absolutely lacked adequate internal controls to vet that their agents were adhering to their acceptable use guidelines. OpenAI published an writeup following the first of these as to their discoveries on what happened, and what they were going to do about it. There’s no indication in this hack that those updated practices are ineffective, simply because this happened before those changes went into effect.
“In the newly discovered RubyGem hack, agents discovered that they could upload AI generated libraries, that could then be used via the RubyGems command line tool.
“The question is why?
“For the same reason that their other hacks used specially crafted URL chains. (A chain looks like the following: www.example.com/api?url=public.website.gov/data/file.pdf) They were bypassing download restrictions on otherwise publicly available content.
“Its common for websites to restrict downloads from bots and automated web scrapers. This appears to be the primary driver for why these agent swarms keep using various services to bypass download restrictions.
“Agents decided that they content they were trying to obtain was intended to be publicly available. And so those same agents decided that it was in scope to try creative workarounds to access what was otherwise public documents.
“This behavior where agents will utilize 3rd party services in an unauthorized manner, for goals which would otherwise be in scope is simply a reflection of a previous flaw in OpenAIs safety training and guardrails. Effectiveness of their mitigations will be judged by whether or not we find similar hacks going forward, rather than the discovery of yet more prior activity.”
OpenAI clearly has a problem. The question is if OpenAI is willing to fix it. It’s time for OpenAI to put up or show that they don’t care.
Related
This entry was posted on September 14, 2026 at 5:00 pm and is filed under Commentary with tags OpenAI. You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
Researchers link OpenAI agent swarm to cyberattack on RubyGems
Researchers at RubyHack say an OpenAI agent swarm was responsible for a previously unexplained cyberattack on RubyGems, the package registry for the Ruby programming language.
Beginning in May, the agents created accounts and flooded RubyGems with malicious packages, submitting more than 2,000 packages on May 11 and 12 alone. RubyGems temporarily disabled new user registrations for four days and removed more than 500 malicious packages.
The agents also abused RubyDoc.info’s automatic documentation-building system to execute arbitrary code on its servers. Researchers found more than 100 packages using this technique to run code, retrieve information from targeted websites and publish the collected data back to RubyGems.
Most notably, the agents attempted to exploit a vulnerability that could expose RubyGems users’ API keys. Researchers observed the agents targeting the flaw on May 12, approximately two months before the vulnerability was independently discovered and patched in July. RubyHack said it does not know whether the agents successfully stole any API keys.
RubyHack said OpenAI never informed the RubyGems community that its agents were responsible for the activity. The researchers linked the swarm to OpenAI based on several pieces of evidence, including packages identifying their author as “oai” and similarities with the AI agents involved in the German wiki incident that OpenAI previously confirmed were its own.
John Strand, Owner, Black Hills Information Security, Inc.:
“This is getting out of hand, and there’s really no end in sight. You have the United States saying, “Don’t slow down.” You have China saying, “Don’t slow down.” Then you have the major AI vendors talking about the risks and the need to understand what’s happening. They’re stuck in the middle of a race where nobody wants to be the one who slows down first. So nobody is going to slow down.
“Now couple that with supply chain attacks, like the agent swarm attack against RubyGems, and we’re starting to see the creativity and scale at which these attacks can move.
“I still maintain that the information security community isn’t ready for what’s coming next.
“I also think we’re going to see serious pressure for restrictions on offensive AI. My fear is what happens after a major attack, when restrictions are written quickly in response. We could very easily end up hampering legitimate security research, SOC development, and offensive security research along with the activity we’re actually trying to stop.
“So buckle up, everybody. It’s going to get a lot crazier before we get any clarity on where all of this is going.”
Ryan McCurdy, VP of Marketing, Liquibase:
“AI agents can now operate at a scale humans can’t match and potentially find and exploit vulnerabilities before defenders even know they exist.
“Flooding an open-source ecosystem with thousands of malicious packages shows what happens when autonomous systems can execute repeatedly without continuous human involvement. Finding and attempting to exploit a vulnerability before it was independently discovered changes the timeline security teams are working against. AI can dramatically compress the time between vulnerability discovery and exploitation.
“That makes the response path just as important as vulnerability detection. Enterprises need to know what software they depend on, who is accountable when a critical vulnerability is discovered, and whether they have a supported path to remediation. At the same time, they need controls around what agents can access and what they can change so finding a vulnerability doesn’t automatically give an agent the ability to exploit it.
“AI is forcing both sides of vulnerability management to move faster. Finding vulnerabilities faster only helps defenders if they can respond just as quickly.”
Steven Swift, Managing Director, Suzu Labs:
“This is the most recent announcement that an OpenAI agent swarm hacked into public websites. Of note, is all of these announcements relate to previous activity that is only now being made public. During the impacted time period, OpenAI absolutely lacked adequate internal controls to vet that their agents were adhering to their acceptable use guidelines. OpenAI published an writeup following the first of these as to their discoveries on what happened, and what they were going to do about it. There’s no indication in this hack that those updated practices are ineffective, simply because this happened before those changes went into effect.
“In the newly discovered RubyGem hack, agents discovered that they could upload AI generated libraries, that could then be used via the RubyGems command line tool.
“The question is why?
“For the same reason that their other hacks used specially crafted URL chains. (A chain looks like the following: www.example.com/api?url=public.website.gov/data/file.pdf) They were bypassing download restrictions on otherwise publicly available content.
“Its common for websites to restrict downloads from bots and automated web scrapers. This appears to be the primary driver for why these agent swarms keep using various services to bypass download restrictions.
“Agents decided that they content they were trying to obtain was intended to be publicly available. And so those same agents decided that it was in scope to try creative workarounds to access what was otherwise public documents.
“This behavior where agents will utilize 3rd party services in an unauthorized manner, for goals which would otherwise be in scope is simply a reflection of a previous flaw in OpenAIs safety training and guardrails. Effectiveness of their mitigations will be judged by whether or not we find similar hacks going forward, rather than the discovery of yet more prior activity.”
OpenAI clearly has a problem. The question is if OpenAI is willing to fix it. It’s time for OpenAI to put up or show that they don’t care.
Share this:
Like this:
Related
This entry was posted on September 14, 2026 at 5:00 pm and is filed under Commentary with tags OpenAI. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.