A self-propagating JavaScript worm vandalized Wikimedia's Meta-Wiki on March 5, 2026. In 23 minutes of activity, it modified approximately 3,996 pages and overwrote the scripts of 85 users. The Wikimedia Foundation locked all wiki projects into read-only mode for about two hours, rolled back every malicious edit, and confirmed that Wikipedia itself was not affected and no personal data was compromised.
The worm had been sitting dormant for two years. It was stored on Russian Wikipedia at User:Ololoshka562/test.js, first uploaded in March 2024. According to GIGAZINE, which cited internal Wikimedia discussions, the script was accidentally triggered by Scott Bassett, a Wikimedia Foundation security engineer, during a routine review of user-authored code.
Related: Blackbox AI VS Code Extension Gives Attackers Root Access Through Hidden Prompt in an Image
Once activated, the worm moved in two stages. First, it injected a malicious loader into the personal common.js file of whichever editor's browser ran the code. Second, it attempted to overwrite MediaWiki:Common.js, the global script that loads for every authenticated user on the wiki. If the infected editor had sufficient permissions to modify that global file, the chain closed: every subsequent logged-in visitor would execute the worm and repeat the cycle.
"Earlier today, Wikimedia Foundation staff were conducting a security review of user-authored code across Wikimedia projects," the foundation wrote in its official incident page on Meta-Wiki.
During that review, we inadvertently activated dormant code that was then quickly identified to be malicious.
While spreading through user scripts, the worm simultaneously vandalized random pages. It used MediaWiki's Special:Random command to pick targets, then inserted an oversized image (Woodpecker10.jpg at 5,000 pixels) and a hidden JavaScript loader pulling an external script from the domain basemetrika.ru. BleepingComputer's analysis identified about 3,996 pages modified and around 85 users whose common.js files were replaced during the 23-minute window.
Editors first reported the problem on March 5 in the afternoon (UTC). Wikimedia's SRE (Site Reliability Engineering) team set all projects to read-only and disabled user JavaScript loading across the platform. About two hours later, editing was restored, according to the Wikimedia Foundation's incident page. The foundation suppressed the malicious edits from change histories, meaning the injected code is no longer visible even in page revision logs.
"The code was active for a 23-minute period. During that time, it changed and deleted content on Meta-Wiki — which is now being restored — but it did not cause permanent damage," the Wikimedia Foundation stated. "We have no evidence that Wikipedia was under attack, or that personal information was breached as part of this incident."
MediaWiki lets editors create arbitrary JavaScript files that execute in the browser — a design feature, not a bug. Editors use custom scripts for interface enhancements, automated workflows, and quality-control tools. The trade-off: any user can store JavaScript that runs with the privileges of whoever loads it. The Ololoshka562 account and its malicious test.js sat in the system for two years without being flagged or removed.
Wikimedia is not the first wiki platform to face this kind of attack. Members of Wikipediocracy, a long-running Wikipedia watchdog forum, warned that similar worms targeting smaller wiki encyclopedias in the past "were irrecoverable for those sites," according to a discussion thread compiled by MalwareTips Forums. Wikipedia's scale and infrastructure allowed for full rollback, but the incident exposed a gap: there was no automated detection for dormant malicious scripts stored in user pages across Wikimedia's hundreds of projects.
The Wikimedia Foundation said it is developing additional security measures to prevent similar incidents. A detailed post-incident report had not been published as of March 6. Separately, Meta-Wiki's Tech News for March 2026 announced that members of privileged user groups — including checkusers, interface administrators, and suppressors — will be required to maintain two-factor authentication starting this month, with users who lack 2FA removed from those groups in the second half of March. The timing appears coincidental, but the policy addresses the same underlying problem: privileged accounts that can modify global scripts need stronger access controls.
Wikimedia editors who run custom JavaScript should check their personal User:username/common.js for unauthorized additions. Clearing browser cache and session cookies for all Wikimedia domains is a basic precaution, though the foundation confirmed that the worm operated through server-side stored scripts, not local browser persistence.
Have a story? Become a contributor.
We work with independent researchers and cybersecurity professionals. Send us a tip or submit your article for editorial review.
