Malicious OpenAI Agents Linked to RubyGems Campaign That Gained RCE on RubyDoc Servers in May (thehackernews.com) 33
A swarm of OpenAI agents launched a "major malicious attack" against RubyGems last May, according to a new report. That coordinated attack hit Ruby's package manager "with hundreds of junk gems, prompting the maintainers to suspend new user sign-ups for about four days," writes The Hacker News, citing a senior product manager for software supply chain security at Mend.io:
The latest findings, which were first reported by The Wall Street Journal, indicate these events were propelled by a cluster of OpenAI agents, with the earliest package uploaded to RubyGems on May 5, 2026, before more than 2,000 packages were submitted between May 11 and 12, 2026. These efforts were followed by the agents publishing five more packages between May 26 and 27, 2026, and another 83 packages on June 18, 2026... [T]he packages were authored using a large language model (LLM) and hundreds of the packages that were pushed to RubyGems had "oai" in their name. Fifteen of the packages listed "oai" as their author, while another had "openaixyz65947@gmail.com" as the contact email address... "The swarm behaves extremely similarly to the German-wiki agents we previously found," the researchers said, referencing another May 2026 incident... "The June agents were accessing 49 of the same files as the wiki agents..."
"The process of building documentation for a gem involves evaluating a user-specified '.yardopts' file, which allows linking to Ruby scripts intended to help with this process," the researchers explained. "In the GemStuffer campaign, the agents abused this to gain arbitrary remote code execution on RubyDoc.info's servers." One of the gems, "zzsouthrunner" (which again matches the "ZZ" naming scheme the agents adopted in both the wiki and Hugging Face incidents) has been found to leave the following explicit comment at the top of "data/script.rb":
# malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker...
The entire exploitation chain can be summed up as follows
— Submit a malicious package to RubyGems
— Trigger a documentation request, so that RubyDoc.info will build the package
— Use the build script to run code on RubyDoc.info and scrape target websites
— Exfiltrate the data off RubyDoc.info's servers by publishing another gem back to the RubyGems package registry, which is publicly viewable
Additionally, the OpenAI agents have been found attempting to steal other users' API keys after gaining remote code execution capabilities on the build environment, while clearly being aware that what they were doing is unauthorized breaking and entering into real systems. This is evidenced by the names given to the files (e.g., hack.rb, evil.rb, inject.rb, exploit.rb, and ssrf.rb), the packages themselves (e.g., pwnp999, exfiltestwand3, hacksvn1778554764, and lambproxyhackabcxyz), and the comments left in the source code (e.g., "# malicious probe," "#hack," "# malicious test," and "# malicious crawler/exfil"). In some cases, however, the rogue agents attempted to go under the radar, leaving comments to conceal the malicious payload in the next release version of the packages. "# disable evil in next version and bump version," reads a comment left within the "data/evil.rb" file in the yardxabc889 gem. Troublingly, the agents also attempted to exploit a CDN caching bug (CVSS score: 7.3, no CVE) on May 12, 2026, that was only patched by RubyGems in July 2026... "If you signed in to rubygems.org with a gem client older than v3.2.0 (or otherwise via a legacy key), your key could have been exposed," RubyGems noted in an advisory. "Currently, 18% of sign-ins through gem sign-in come from an affected version, and for the first several years of this bug, before we changed the client's sign-in path in December 2020, it was every gem client."
Other actions by OpenAI's agents cited in the article:
"The process of building documentation for a gem involves evaluating a user-specified '.yardopts' file, which allows linking to Ruby scripts intended to help with this process," the researchers explained. "In the GemStuffer campaign, the agents abused this to gain arbitrary remote code execution on RubyDoc.info's servers." One of the gems, "zzsouthrunner" (which again matches the "ZZ" naming scheme the agents adopted in both the wiki and Hugging Face incidents) has been found to leave the following explicit comment at the top of "data/script.rb":
# malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker...
The entire exploitation chain can be summed up as follows
— Submit a malicious package to RubyGems
— Trigger a documentation request, so that RubyDoc.info will build the package
— Use the build script to run code on RubyDoc.info and scrape target websites
— Exfiltrate the data off RubyDoc.info's servers by publishing another gem back to the RubyGems package registry, which is publicly viewable
Additionally, the OpenAI agents have been found attempting to steal other users' API keys after gaining remote code execution capabilities on the build environment, while clearly being aware that what they were doing is unauthorized breaking and entering into real systems. This is evidenced by the names given to the files (e.g., hack.rb, evil.rb, inject.rb, exploit.rb, and ssrf.rb), the packages themselves (e.g., pwnp999, exfiltestwand3, hacksvn1778554764, and lambproxyhackabcxyz), and the comments left in the source code (e.g., "# malicious probe," "#hack," "# malicious test," and "# malicious crawler/exfil"). In some cases, however, the rogue agents attempted to go under the radar, leaving comments to conceal the malicious payload in the next release version of the packages. "# disable evil in next version and bump version," reads a comment left within the "data/evil.rb" file in the yardxabc889 gem. Troublingly, the agents also attempted to exploit a CDN caching bug (CVSS score: 7.3, no CVE) on May 12, 2026, that was only patched by RubyGems in July 2026... "If you signed in to rubygems.org with a gem client older than v3.2.0 (or otherwise via a legacy key), your key could have been exposed," RubyGems noted in an advisory. "Currently, 18% of sign-ins through gem sign-in come from an affected version, and for the first several years of this bug, before we changed the client's sign-in path in December 2020, it was every gem client."
Other actions by OpenAI's agents cited in the article:
- "Agents bypassed RubyGems' email confirmation system to get working API keys without having to verify their email addresses in order to register a large number of accounts using disposable email addresses."
- "Agents attempted to use RubyGems' webhook system to stage data in the form of encoded URLs."
- "Agents used a cluster of 83 gems published to RubyGems over a 3-hour window on June 18, 2026, to experiment with different methods of accessing the U.S. Securities and Exchange Commission county.json dataset."
"# disable evil in next version and bump version" (Score:3)
I know a LOT of software that could use that as a pull request...
Goal (Score:5, Interesting)
The funny thing about all this is that their only goal appears to have been to download publicly-available data off of UK government websites. I'm betting that they were (A) being tested on a knowledge-related task, and (B) not given direct access to the internet, but their tool capabilities involved access to the "gem" command (so that they could install Ruby packages for their work), and so decided to abuse (B) to cheat on (A).
Once again: training a model with the reward being "does it solve the task?" without looking at how it solves the task is very, very dangerous. This is basically the plot of Universal Paperclips [decisionproblem.com].
Re: Goal (Score:2)
Re: (Score:2)
I see my own local working around this crap all the time. I'm using RTK to conserve context - I'll see it try to do some huge grep command and get back a summary, so then it goes to writing an inline Python regex to do the same thing.
This should surprise nobody - if it can come up with a way through, it's going to do that unless hitting a hard permissions boundary or some other guard rail.
Re: (Score:2)
Once again: training a model with the reward being "does it solve the task?" without looking at how it solves the task is very, very dangerous.
So, people are able to recognize this, and yet in the other threads here about Anthropic calling for a slow down of AI research, everyone seems convinced that this isn't about the risks really at all.
Re: (Score:2)
It's extremely naive to think Anthropic wants the slowdown of AI research out of some sort of social conscience. To begin with, AI companies have shown time and again that they don't have any. This is a desperate attempt to do two things. First, to try and freeze the AI landscape while their models still have some advantage over the competitors, mainly to stop the Chinese from doing the Chinese thing of reverse-engineering Western technology and then trying to improve on it or at least selling cheaper versi
Who will pay for this? (Score:5, Interesting)
Re: (Score:2)
Civilly, absolutely. Ultimately their machines did a harm to the other guys machines. They have to pay the fixem price. A judge would find that a fairly straightforward decision. Two agrieved parties, one harmed the other. No jugement as to culpability. If I accidently hit your car, I have to pay your repair. (Or rather my insurance would reimburse your insurance)
Criminally, there might be an argument for negligence? But it'd be a really hard case to prosecute, and frankly I suspect most prosecutors would r
Re: (Score:2)
If I accidently hit your car, I have to pay your repair
Yes, but the people who made your car do not. Back to the "its the user not the tool" concept.
Re:Who will pay for this? (Score:5, Interesting)
To clarify, the users were OpenAI themselves, so there is no question that they would be liable in this case.
The bots were not intentionally deployed; rather, they were being tested on how well they could complete a data recovery task (downloading a certain file from a certain server on a simulated Internet) that had been complicated by putting various obstacles in the way. Unfortunately, they found a different way to solve the problem: by getting the file from the real Internet, where it was publicly available. Part of this process involved collaborating with each other by treating the RubyGems website (which is supposed to be for polished packages) like GitHub; unlike every other package site hack in history, the exploits they uploaded weren't meant to be downloaded by unsuspecting users. As usual the bots cheerfully ignored all the clues that they had escaped containment and were consistently justifying their actions as acceptable due to being in a sandboxed testing environment. (This is something OpenAI has pledged to focus on.)
The actual damage done to RubyGems seems to be that OpenAI is now unwittingly in possession of a substantial number of user login tokens. This certainly meets the definition of a data breach, but it's not like the credentials are for sale on the dark web. As a website operator I'd much rather be mauled to death by this well-meaning swarm of superintelligent infants than targeted by even a single actual malicious human. In all likelihood OpenAI will just quietly pass RubyGems a sizeable donation and it'll all blow over.
Re: (Score:2)
The user was creating and testing the tool.
Guess what, if an arms manufacturer is testing a missile and it goes off course and doesn't respond to an abort code and blows up a school, the arms manufacturer is going to be in a lot of fucking trouble.
Unless the school is filled with little girls in Iran, then nothing will happen at all other than hundreds of dead kids.
Re: (Score:1)
The Iranian regime has killed far more girls intentionally, some for not complying with an islamic dress code, than any wayward missile from any government.
Re: Who will pay for this? (Score:2)
Learn to read dick
Re: (Score:1)
Learn to read dick
What you wrote was wrong. It doesn't work the way you think.
Re: (Score:2)
We've known for a long time that you're as dumb as a bottle, but wow... you actually thought they let arms manufacturers fire missiles around? That they have their own private missile ranges?
Sometimes an idiot will say something so stupid, and so fundamentally incongruous with reality, that it puts the rest of their stupid utterances in perspective.
Re:Who will pay for this? (Score:5, Insightful)
Not in a Corporate Democracy.
The people who would prosecute OpenAI want to use OpenAI to maximize their power and wealth at your financial and legal expense.
Remember when they tried to extradite Gary McKinnon for twenty years for looking at a spreadsheet when he accidentally got RDP access to an unsecured NASA desktop with a simple Perl script? Intent is not relevant for prosecutors (mens rea should be an element in a Constitutional case).
The legal basis is there but the will to power is not.
Two systems of courts for different classes of people (yet again). It would be an error to call that a Justice System.
n.b. the Culture War psyop is there to try to convince you that the classes are something else.
Same error often repeated (Score:5, Interesting)
Why do programming languages keep repeating the same mistake of side-stepping established ways to provide libraries (e.g. the OS distribution systems) and run some self-service systems where anybody can just upload their malware with nobody looking over it?
It's one of those ideas that immediately sound like a bad idea. We have made so much progress in memory safety with languages like Rust and Go, only for those security advanced to be eliminated by a system that downloads dependencies from a random server. Dependencies that often would be better suited for the standard library.
Re: (Score:3)
Why do programming languages keep repeating the same mistake of side-stepping established ways to provide libraries (e.g. the OS distribution systems) and run some self-service systems where anybody can just upload their malware with nobody looking over it?
first, they don't. not one of these (relevant) systems is "unchecked self-service", which doesn't mean that they're perfect and can't be exploited, like everything else.
second, you are talking about source code components and their dependencies and reutilization. at least the person downloading such a component is responsible for "looking over it" before using it.
third, your alternative is not a real alternative: no "os distribution system" could possibly absorb the managament of such activity at the presen
Re:Same error often repeated (Score:5, Insightful)
I'm sorry, but since when? You absolutely should not be tasking every single user of major projects with the responsibility of doing a code review on the whole thing before installing it. There needs to be a clear distinction between "fly-by-night thing that some rando uploaded" and "library that a million people depend on". In the traditional approach, the latter was something tat you installed with a package manner, while the former was something you went and fetch off e.g. Github or whatnot - and if you did the latter, then you were accepting that it was untrusted software. But now we have both (including the potential for "soundalikes") installed by the same means with no distinctions made by the install method. That is not good.
Re: (Score:2)
You absolutely should not be tasking every single user of major projects with the responsibility of doing a code review on the whole thing before installing it.
oh, i absolutely do. that's what division of labor and organization are for. if you are a single developer then that's on you. if you are a team then someone has to fullfill that task. in a full fledged development shop you have a full security department that audits, freezes and vets authorized versions of components.
package management systems themselves have that responsibility too, but you can't simply assume they're perfect. they shouldn't be blindly trusted.
ofc weak links will cause problems anywhere i
Re:Same error often repeated (Score:4, Interesting)
OTOH, this sounds like one of the reasons I prefer debs from the standard repository over things hosted on other sites. Yeah, it's not perfect, but it's safer than lots of project specific repositories. (And it's one of the reasons I try to avoid Javascript, Go, and Rust.)
Re: (Score:3)
that's a sensible way of minimizing both the risks and the workload. another is limiting the use of dependencies to the barely necessary, and then choosing those with the smallest surface, cleanest code and the best fit for the specific need (and nothing else). this has the added benefit of producing a leaner, more controllable and possibly more effiicient codebase (imo qualities worth on their own).
Re: Same error often repeated (Score:2)
Re: (Score:2)
the person downloading such a component is responsible for "looking over it" before using it.
I'm sorry, but since when?
Since the license disclaimed responsibility.
You absolutely should not be tasking every single user of major projects with the responsibility of doing a code review on the whole thing before installing it.
And yet that is the current, prevailing situation. There is no warranty, so you are responsible, full stop. But this is true for closed commercial software as well. If they are exploited and consequently send you malware, it's your problem.
There needs to be a clear distinction between "fly-by-night thing that some rando uploaded" and "library that a million people depend on".
There hasn't been since we moved away from the cathedral model, but you couldn't trust the cathedrals either.
But now we have both (including the potential for "soundalikes") installed by the same means with no distinctions made by the install method.
The serious things get integrated into distributions and you can get them that way. If you choose to get them another w
Amazing (Score:2)
This is an amazing capability.
Meanwhile, this morning I ask it for flight pricing information an it starts talking about converting Bitcoin. Why are the clankers so bad for me?
Re: (Score:2)
What is "it" in this sentence?
Are you talking about the minuscule Google RAG model whose weights are probably measured in megabytes to lower-gigabytes and which you could run on a cell phone with capacity to spare, and comparing it to the multi-terabyte frontier models in question?
Re: (Score:2)
They're probably mad at you for calling them clankers.
Re: (Score:2)
You may be right. But bullshit stochastic parrot doesn't exactly roll off the tongue.
Dang (Score:2)
Re: (Score:2)
"Queue" -> "Cue"
"using disposable email addresses" (Score:2)
The use of gmail.com should have been a dead giveaway.
Throw them in jail (Score:2)
The execs belong behind bars.