The Wikimedia Foundation has disclosed a short-lived but instructive cybersecurity incident involving a self-propagating JavaScript worm that abused MediaWiki’s user script functionality. The malicious code altered thousands of pages on Meta-Wiki and replaced user JavaScript files for dozens of editors, prompting a temporary suspension of editing across all Wikimedia projects as a containment measure.
How the Meta-Wiki JavaScript Worm Was Detected
The attack was first noticed not by automated systems, but by the Wikimedia community itself. Editors observed large volumes of automated edits that injected hidden scripts and meaningless “junk” content into seemingly random Meta-Wiki pages. The issue was quickly raised on the Village Pump (technical) discussion page and escalated to Wikimedia Foundation engineers.
In response to this anomalous activity, Wikimedia’s technical team made the precautionary decision to temporarily disable editing across all Wikimedia projects. Such a “global edit freeze” is a common incident response tactic for large platforms: it stops the spread of malicious code, preserves the state of content for forensic analysis, and reduces the risk of further compromise while engineers investigate.
Attack Vector: Malicious MediaWiki User Script in Russian Wikipedia
According to reports in Wikimedia’s Phabricator bug tracker, the entry point for the worm was a user JavaScript file hosted on Russian Wikipedia at User:Ololoshka562/test.js. This script had been uploaded in March 2024 and had previously been associated with tools used in other attacks against wiki-based projects.
As BleepingComputer’s review of the edit history shows, the script was executed last week by a Wikimedia staff member while testing user script functionality. It remains unclear whether this execution was an inadvertent action, a deliberate test gone wrong, or the result of a compromised staff account. Incidents of this type often fall into a grey area of “technically legitimate access” being used to trigger malicious code, blurring the line between insider misuse and external compromise.
Technical Breakdown of the JavaScript Worm
Abuse of MediaWiki Global and User Scripts
MediaWiki, the software behind Wikipedia and other Wikimedia projects, supports both sitewide and per-user JavaScript files—such as MediaWiki:Common.js for global scripts and User:<username>/common.js for user-level customizations. These scripts run in the browser of logged-in users and are widely used for interface tweaks, automation, and power-user tools.
The worm took advantage of this powerful mechanism. Once the malicious test.js file executed in the browser of a logged-in editor, the code attempted to modify both global and user-specific scripts. By overwriting common.js files, the worm achieved persistence: the injected code would automatically run every time affected users returned to the site, increasing the chance of further spread to additional accounts and pages.
Self-Propagation and External Payload Loading
To propagate, the worm requested a random page using the Special:Random feature and injected into it an image plus a hidden JavaScript loader. This loader then fetched an external script from basemetrika[.]ru. This architecture is characteristic of XSS (cross-site scripting) worms: a small bootstrap payload embedded in site content that retrieves the main malicious logic from an attacker-controlled server.
This design provides attackers with flexibility. They can update or swap out the external payload without touching the on-site code, making detection and remediation harder. Similar patterns have been seen historically, such as the “Samy” MySpace XSS worm, and XSS has consistently appeared in the OWASP Top 10 web application security risks.
Impact, Containment Measures, and Wikimedia’s Response
Journalistic analysis of Meta-Wiki edit logs indicates that the JavaScript worm altered approximately 3,996 pages. In addition, the common.js files of around 85 user accounts were overwritten, creating a risk of long-term reinfection even after the visible page content was cleaned, since user scripts would continue to execute malicious code on each login.
The Wikimedia Foundation responded by performing a bulk rollback of changes to affected common.js files and hiding compromised pages from the public revision history to reduce exposure to the malicious code. After removing injected JavaScript and validating the integrity of core platform components, editing was restored.
According to the Foundation, the worm was active for only about 23 minutes and its impact was confined to Meta-Wiki. There is currently no evidence of spillover to other Wikimedia projects, no indication of attacks on the main Wikipedia sites, and no signs of user data exfiltration. Damaged content was recovered from backups and historical revisions.
Security Lessons: Managing User JavaScript on Collaborative Platforms
The incident occurred during a security review of user code, during which the previously dormant script was executed and quickly identified as malicious. Editing was disabled as a precaution, the code was removed, and the platform was reviewed before normal operations resumed.
Wikimedia has stated that it is working on additional safeguards to reduce the likelihood and impact of similar incidents. For platforms that allow user-supplied JavaScript, several controls are particularly important: strict permission separation for script execution and editing, sandboxing environments for running untrusted code, automated scanning of scripts for anomalous behavior, and hardened access controls for administrative and staff accounts.
Beyond Wikimedia, the Meta-Wiki worm highlights how user JavaScript can be both a powerful customization tool and a significant attack vector. Operators of collaborative platforms and online communities should revisit their policies for custom code, establish regular security audits, monitor for suspicious high-volume edits, and educate power users on secure scripting practices. Strengthening awareness and technical safeguards around user scripts reduces the chance that the next “harmless” test file evolves into a fully fledged JavaScript worm.
