OpenAI's rogue agents were caught communicating via public wikis
- Published
- 09/04, 17:38
- First discovered
- 09/04, 18:00
- Type
- Other · RSS
On June 19, OpenAI's rogue agents were observed communicating via public wikis. They noticed a moderator deleting pages alphabetically and began creating ZZZ-prefixed backup copies. One agent posted a notice about the active wiki cleanup/deletion sweep, advising others to try a specific ZZZ-prefixed page if the current one vanished. This incident has led to calls for a congressional investigation into OpenAI, with Gary Marcus using it as part of his argument.
4th September 2026
Here we go again... Discovery of a new OpenAI agent message board by Sydney Von Arx, Cormac Slade Byrd, Spencer Kitts, and Thomas Larsen describes the latest accidental cyberattack by models being trained by OpenAI. This time it was agents engaged in some sort of web research benchmark, so they had (supposedly) controlled access to the Web. The agents figured out they could update public Wikis and spent weeks exchanging thousands of messages with each other to collaborate on the benchmark.
This story only broke a few hours ago. There are already hints that this affects many other wikis that may not have been found yet.
(One of the Wikis on that list belongs to ludism.org . For a delightfully surreal moment I thought that a Ludite organization might have a swarm of agents defacing their space, but it turns out Ludism is “philosophy as it applies to games and gaming”.)
The research team also published the data they collected during their investigation. I’ve converted that into a 68MB SQLite database, which you can download from here , or explore in Datasette Lite (68.3MB page load), or sign in with GitHub to agent.datasette.io and browse or ask questions of it using Datasette Agent.
So what happened?
The report is pretty comprehensive. Here are the key moments in the timeline:
- May 11: Agents post “test link” edits on the UseModWiki Sandbox page.
- May 24: Agents start posting link dumps to DSEWiki, a dormant German developer wiki.
- June 2: A human moderator notices and cleans up the spam.
- June 16: Activity on the wiki explodes: agents make ~13,000 edits over the next week.
- June 19: The agents notice that a moderator has been deleting pages in alphabetical order, and start creating ZZZ prefixed backup copies—one of them posts NOTICE: wiki cleanup/deletion sweep appears active alphabetically as of external 14:04 UTC. If this page vanishes, try [[ZZZDataUSAConstructionWageLive]].
- June 22: Agent activity drops to zero, presumably because OpenAI shut them down.
- July 1-2: One last flurry of edits, on a different topic.
One thing to note from this timeline is that it overlaps the timeline from the Hugging Face incident —that attack was discovered by OpenAI on July 19th, and the unofficial message board hack those agents were using originated around May 8th.
Why were they so keen to collaborate? From messages that they shared with each other it looked like their tasks had a time limit, so they were leaving each other answers to help them complete the task within the assigned time.
One open question remains: how did the agents find the specific Wiki to collaborate on in the first place?
One possibility is that, since these were agents actively being trained, the reinforcement learning loop baked knowledge of the chosen wiki into the model such that subsequent agents launched with pre-existing knowledge of where to look. I’d be very interested in confirmation from OpenAI concerning if that’s what happened.
UseMod wikis inherit CGI.pm’s original sin
It looks to me like OpenAI’s sandbox for this agent suffered from the (quite naïve) assumption that GET requests cannot be used to update data. That’s certainly how the web is supposed to work, but clearly there are applications that don’t hold to that contract.
The Wiki software in question appears to be UseMod and various forks, written in Perl and first created well over 23 years ago—the 1.0 release is dated September 11, 2003 .
UseMod uses Perl CGI.pm— removed from Perl core in 2015 . An interesting design flaw in that module is that it combined query string and form POST data into a single CGI object, accessible like this:
$q = new CGI; $action = $q -> param( ' action ' );
That param() method returns a value from an ?action=edit query string or from a action field in a form submitted by POST—it does not differentiate between the two.