Wikipedia:Wikipedia Signpost/2026-03-10/Special report
What actually happened during the Wikimedia security incident?: A horrifying exploit took place, which could have had catastrophic and far-reaching consequences if used maliciously; instead, it seems to have happened by accident and was used for childish vandalism. How did this happen, and what did the script actually do?
← Back to Contents
View Latest Issue
10 March 2026
File:Windows Blue Screen on room full of computers.JPG
Grj23
CC0
277
100
800
Special report
## What actually happened during the Wikimedia security incident?
Contribute —
Share this
* PDF download
* E-mail
* Mastodon
* LinkedIn
* Facebook
* X (Twitter)
* Bluesky
* Reddit
By JPxG
Recent changes on Meta-Wiki show user accounts with advanced permission posting the message "Закрываем проект", which is Russian for "closing the project".
_This security incident is also the subject of this issue'sopinion essay, and covered in News and Notes._
It has become the talk of the town that somebody set up us the bomb, that we were on the way to destruction, that Wikipedia was hacked, and other such things.
Well, it kind of was.
A horrifying exploit took place, which could have had catastrophic and far-reaching consequences if used maliciously; instead, it seems to have happened by accident and was used for childish peepee-poopoo vandalism.
The official statement, which you can see here, does not say a whole lot about specifically what happened:
“ | Earlier today (March 5, 2026), Wikimedia Foundation staff were conducting a security review of user-authored code across Wikimedia projects. During that review, we inadvertently activated dormant code that was then quickly identified to be malicious. The code was active for a 23-minute period. This caused page deletions on Meta-Wiki that have since been restored. To prevent the script from spreading further while we investigated, Wikimedia projects were set to read-only for about 2 hours, and all user JavaScript was temporarily disabled for most of the day. Affected pages have since been restored, and we believe no permanent damage has occurred as a result of this code. We have no reason to believe that Wikipedia was actively under attack or that personal information was breached as part of this incident. At this point, the impact of the malicious code has been cleaned up, and user JavaScript has been re-enabled. We are actively developing further security mitigations for user JavaScript in consultation with the community, to make incidents of this kind much more difficult to happen in the future. | ”
---|---|---
— Wikimedia Foundation
This is not very enlightening, so let's take a closer look.
The actual script, whose source code can be seen from the Phabricator ticket page, is relatively simple. It does not do anything particularly horrifying or complicated; mostly it's just dumb schoolkid vandalism. It cannot actually get into the backend database or the server's shell, which is where private data is stored, and irreversible actions can be taken: all it can do is make a big mess on the wiki.
The way it works hinges on the fact that, on MediaWiki, all users have a page called "common.js", which is where userscripts go. If you're logged in, yours is here; mine is here. On this page, you can put code that is automatically run whenever you load a page on the website. They can either be written in the file itself, or loaded from somewhere else.
In mine, for example, I have it (among other things) load User:JPxG/Difformatter.js, a script I wrote that gives me buttons in the editing box to automatically format external diff URLs (like my 123,456th edit, whose URL is `https://en.wikipedia.org/w/index.php?title=&diff=prev&oldid=1336463538` and looks like this) into internal links (like `Special:Diff/1336463538`, which looks like this). Most userscripts do something along these lines. There are a great number of them, and there is a semi-active newsletter for new ones, which I at one point wrote an issue of.
There is also a page on every wiki called `MediaWiki:Common.js`, which the English Wikipedia has here, and Meta-Wiki has here. This is a version of the same page that runs for everybody on the entire site. Because this could be very easily used to make a huge mess, either intentionally or unintentionally, access to it is very limited: I am a template editor and an edit filter manager and one of the thousand or so sysops on Wikipedia who have to be elected, and I could put Goatse on the Main Page if I wanted to, but I still cannot edit the site's common.js unless I make a request for another userright, "interface administrator". There are only fifteen of these; in addition to being administrators, they are all serious-business technical editors like Izno and Oshwah who can be trusted around high voltage.
Anyway, here is what Ololoshka562's script does:
* Loads jQuery, gets the account name of the current user, and checks to see if it has already infected the site.
Literally, it fetches the current site's MediaWiki:Common.js and checks to see if it has "Ololoshka562" anywhere in it.
* Tries to edit the sitewide common.js, and replace it with a gigantic block of gibberish. This gibberish is also JavaScript, but it's encoded as a URL is, so it is kind of hard to read.
The script de-gibberishifies it later, so the only reason it's that way is to make it hard to read the code. Presumably, if it was just written directly, it would be obvious what it did, so it is kind of munged up.
* Also edits the current user's common.js, and replace it with the same bolus.
Only interface administrators can edit the sitewide common.js, so this allows it to work on people who aren't intadmins.
* Tries to use Special:Nuke three times.
If you aren't an administrator, you can't do anything from this page, but I can use it to delete massive numbers of pages. That is what this script does.
* Gets twenty random pages and tries to vandalize them.
Adds a photograph of two woodpeckers mating, and then add a tracking script to load... something... from some sleazy-looking website I've never heard of. This site was, by March 2026, not only nonexistent but also unregistered.
* Gets twenty more random pages, and tries to delete them.
If you aren't an administrator this won't do anything.
The actual bolus of crap that it loads does a few more annoying things:
* Loads itself.
* Makes every link to a page called "common.js" unviewable, so you cannot fix it from the normal web interface.
* Redefines the `importScript` function so that, when userscripts try to load other userscripts, instead of the local site they load them from cyclowiki.org.
Strewn among this is a bunch of junk that doesn't do anything malicious, and looks like it came from some normal wiki's Common.js (like you would find here to expand and collapse boxes, tables, and so on.
As far as I can tell, this was either made purely for the lulz, or as part of some puerile beef between two random wikis. It doesn't do anything permanent or extremely dangerous; basically everything it does is within the interface that MediaWiki exposes to users. It does _load_ and execute random JavaScript; at the time it was written, whatever was in those offsite URLs could have been some kind of horrifying smallpox code that stole your banking details. However, it didn't do this when it was actually executed, because the URL didn't exist anymore. Whatever heist this was originally cooked up for, if it was carried out at all, seems to have been finished and wrapped up years ago. This script is basically just a random grenade that was left lying in a cornfield. It was basically harmless, except in the specific scenario where somebody with extremely powerful sitewide permissions decided to import and run it with full privileges, which is usually something that people do not do. Mostly because this kind of thing can happen as a result.
Essentially, to carry the analogy further, a grenade lying in a random cornfield is not a particularly dangerous or sophisticated attack against the nation in question. It would cause significant damage if a head of state picked it up off the ground and fixed to take a bite out of it, but under normal circumstances there are people whose job it is to prevent this from happening.
### Why was it the case that this could happen?
In the aftermath of every accident, it is necessary to figure out not just why it happened, but why it was allowed to happen. The "find one guy to yell at" system is alluring, because it is simple, but in most cases it is not sufficient to explain failures. Especially with systems as complex as modern software, it is rarely the case that the person who bumped into the "blow everything up" button is to blame — for starters, why is there a "blow everything up" button in the first place? Was it right next to the light switch?
At the Meta-Wiki page created to discuss the incident, a great deal of confusion ensued. Generally speaking, in the software industry, this is not supposed to happen. Over decades, it has become pretty well understood that some activities are inherently risky, and in most systems there is a framework in place to test them out where it won't blow anything important up.
The basic principle is similar to how, when the army is making some new type of gigantic bomb, and they need to test something by actually blowing it up in real life instead of working it out on graph paper, they go to some sand dunes in the middle of nowhere, even though their offices are in the middle of a densely populated city. Most companies and organizations that develop software have similar arrangements. Indeed, the prevailing practice in most software-related industries is to maintain two copies of infrastructure, called "testing" and "production".
On Wikipedia, there is a single-page version of the Nevada Test and Training range, at the aptly-named Sandbox; there's a whole-website-sized version of it at test.wikipedia.org. The Wikimedia Foundation, which develops a lot of software, has a wide variety of testing environments, which are used for developing the MediaWiki software and testing various things. It's not immediately clear what test was being done here, or why it was being done on the live site, or why it was being done with an account with such high privileges (e.g. an interface administrator).
However, there are some clues. The most likely thing, in any situation like this, is that there wasn't a solidly established framework for whatever was being tested here; either it was a quick, one-off thing that nobody wanted to build a whole testing harness for, or it was something where a whole testing harness would be extremely time-consuming to create. This is not a very good reason to "test in production", as it's called, but it is often necessary on Wikimedia sites. This brings me to my next point.
### MediaWiki doesn't really have version control or testing infrastructure
While MediaWiki may seem like a paragon of orderly version control — after all, every action a user account takes is logged, timestamped, diffable and reversible — in practice it has become kind of a mess.
As an example: on the English Wikipedia there are a great deal of templates and modules. The original purpose of the "template" function was to let the periodic table be displayed on every element's article without having to hard-code it in the article source; they now do basically everything. Templates (which use MediaWiki markup and HTML) and modules (which use Lua) do a dizzying variety of things, and handle virtually all elements of a Wikipedia page that aren't the bare text of articles, and sometimes that. They format infoboxes, display maps, organize maintenance, display citations, display a lack of citations, and most importantly provide functions and components for other templates.
Templates and modules all individually have version histories; for example, Special:History/Template:Section sizes. However, most templates on Wikipedia are meta-templates, which call other templates. For example, I created {{Generating stations in California}}, which is the big expandable box at the bottom of Topaz Solar Farm and Gateway Generating Station that lists all the power plants in the state. All of the categories and links are coded into that template. Navboxes are heavily used, so they are a very straightforward and simplified type of template. But even with this one, if you look at the tree of every template that _the template itself_ uses, you get this:
Pages transcluded onto the current version of this page:
---
Template:Collapsible option
Template:Hlist/styles.css
Template:Navbox
Template:Para
Template:Param value
Template:Param value/styles.css
Template:Replace
Template:Sandbox other
Template:Str len
Template:Template other
Module:Arguments
Module:Color contrast
Module:Color contrast/colors
Module:Navbar
Module:Navbar/configuration
Module:Navbar/styles.css
Module:Navbox
Module:Navbox/configuration
Module:Navbox/styles.css
Module:String
Module:TableTools
Now, you might think 21 templates (what most programmers would call "dependencies") is not a whole lot for something as big as a navbox. But each of them have their own tree of dependencies. For example, here is every template used in {{Collapsible option}}:
Pages transcluded onto the current version of this page:
---
Template:Collapsible option/doc
Template:Crossref
Template:Crossreference
Template:Crossreference/styles.css
Template:Documentation
Template:Documentation subpage
Template:Em
Template:Hatnote inline
Template:High-use
Template:Kbd
Template:Kbd/styles.css
Template:Lang
Template:Para
Template:Param value
Template:Param value/styles.css
Template:Pp-template
Template:Replace
Template:Sandbox other
Template:Section link
Template:Str len
Template:Tag
Template:Template link
Template:Template link code
Template:Template link expanded
Template:Template link
Template:Template other
Template:Tl
Template:Tlc
Template:Tlx
Template:Tnull
Module:Arguments
Module:Documentation
Module:Documentation/config
Module:Documentation/styles.css
Module:Effective protection expiry
Module:Effective protection level
Module:File link
Module:Hatnote
Module:Hatnote/styles.css
Module:Hatnote inline
Module:High-use
Module:Lang
Module:Lang/ISO 639 synonyms
Module:Lang/configuration
Module:Lang/data
Module:Lang/data/iana languages
Module:Lang/data/iana regions
Module:Lang/data/iana scripts
Module:Lang/data/iana suppressed scripts
Module:Lang/data/iana variants
Module:Lang/data/is latn data
Module:Message box
Module:Message box/configuration
Module:Message box/ombox.css
Module:Protection banner
Module:Protection banner/config
Module:Section link
Module:String
Module:Template link general
Module:Transclusion count
Module:Transclusion count/data/C
Module:Unicode data
Module:Yesno
Why does it matter what dependencies a template has? Who cares? Well, there's **no form of inter-page version control whatsoever!**
When you edit {{Generating stations in California}}, for example, you cannot specify that you want to use the version of {{collapsible option}} from 2026-03-09. The only option is to just use whatever the current version happens to be. This means that, from time to time, templates just break for no apparent reason, and the only way to debug or fix them is to go through everything they transclude individually and see what changed.
More relevantly to this incident, there is no way to "create a testing branch" of the whole dependency tree. If you want to make a version of {{Generating stations in California}} that has different colors, you cannot do this on your local machine, or even on a different Wikimedia site. You need to do it on the English Wikipedia specifically, because the English Wikipedia is the only MediaWiki install in the world that has this specific panoply of templates and modules and meta-templates. It's possible to create a separate copy of the template, on the English Wikipedia — most templates (especially complicated ones) have a sandbox subpage where you can test modifications. But there's no way to actually replicate the testing environment without replicating the entire English Wikipedia.
If templates were designed as a programming framework, there might be, but they weren't; they were designed as a way to put the periodic table at the bottom of articles about elements.
This may seem like it has nothing to do with userscripts, and I admit it is a long digression, but I mention it to illustrate a fundamental point about MediaWiki: it's a quarter-century-tall stack of weird kludges built on stuff that in most cases wasn't designed for its current purpose. Any time you are asking yourself why some weird thing happened, this is probably a big part of the answer.
### What is to be done?
I may be biased in my characterization of the situation, but as far as I can tell, the root issue here is likely not that the Wikimedia Foundation employed engineers to poke around with the software, but rather that they did not employ _enough_ engineers to poke around with the software.
The one thing that seems pretty clear is that this was not some kind of sophisticated cyberattack, and there was no Tom Clancy business — it was just a random grenade lying in a cornfield that was for some reason imported and run with one of the highest privilege levels possible. It did not have shell access, and it did not have database admin access, but it did have the ability to load random scripts for viewers of the site.
In all likelihood, whoever Ololoshka562 is had no clue that it was even happening, and certainly did not plant it there to make this incident happen on purpose. This is quite fortunate, because if they had, it could have been a giant global catastrophe. Wikipedia is one of the world's most widely-used websites, and it did not have an arbitrary code execution incident, but seemingly purely by coincidence. This is a pretty narrow bullet-dodge (or nuke-dodge as the case may be), and some changes need to be made.
What changes I cannot say. It's hard to say exactly what went wrong, and whether it was an infrastructure issue or an organizational issue or what — but it was very fucking bad, and it is of paramount importance that it never happen again.
← Previous "Special report"
In this issue
10 March 2026 (all comments)
* Interview
* News and notes
* Special report
* In the media
* Recent research
* Obituary
* Opinion
* Technology report
* Op-ed
* Essay
* In focus
* WikiProject report
* Community view
* Traffic report
* Crossword
* Comix
+ Add a comment
## Discuss this story
To follow comments, add the page to your watchlist. If your comment has not appeared here, you can try purging the cache.
No comments yet. Yours could be the first!
+ Add a comment
Explore Wikipedia history by browsing _The Signpost_ archives.
Home
About
Archives
Newsroom
Subscribe
Suggestions
