Wikipedia In A Worm Alert That Replies When Modifying User Scripts

This morning the Wikimedia community and thousands of users around the world woke up with a disturbing news: a malicious script that was self-replicated came to run within the project infrastructure and began to insert hidden code and modify user scripts into multiple wikis. The first warnings came from Village Pump (technical) from Wikipedia, where editors detected a wave of automatic editions that added invisible JavaScript fragments and vandalism on random pages.

What happened, explained in simple terms: MediaWiki - the software that moves Wikipedia and hundreds of related wikis - allows both administrators and registered editors to load small JavaScript files to customize the site experience. These files can be global (e.g.,MediaWiki: Comun.js) or user specific (e.g.,User: Your Name / common.js). The problem is, if a malicious actor gets a code with editing privileges to run, it can alter those files and cause the code to run on other users' browsers, thus spreading the infection.

According to the public record of the incident in the Wikimedia Foundation's incident system ( Phabicator), the chain of events seems to have started when a script hosted in the Russian Wikipedia was invoked and, from there, a global script with harmful code was modified. A archived copy of the problem script is available in the web memory: test.js file.

Propagation mechanism: the malicious script worked on three simultaneous fronts. First he tried to add a "loader" to the user's personal JavaScript file that had executed it, so that the next time that user sailed connected, he would load the harmful code from his personal space. Second, if that user had the right permissions, the script tried to modify theMediaWiki: Comun.jsfor the code to run for anyone who uses that shared script. And third, the Worm included a routine of vandalism that chose pages at random (through Special: Random) to insert an image and a hidden block that loaded the external code from a malicious URL.

The combination of these three vectors is what makes the incident particularly dangerous: a single browser affected can become seed for an infection replicated in other users and, if it reaches the global script, throughout the project.

The first public analyses replicated by security means indicate that the worm changed thousands of pages and dozens of user scripts. The provisional count that circulated places the editions around 3,996 pages affected and about 85 users who saw thecommon.jsoverwritten. During the immediate response, the Foundation's technical team temporarily limited the possibility of editing in various projects to stop the spread while reversing changes and cleaning references to the injected code.

During the containment phase, the staff of the Foundation also carried out massive restorations of thecommon.jsfrom several users and "deleted" the modified pages so that the malicious changes were not visible in public records. At the time this is written, the injected code has been removed and the edition has been re-established, but key doubts remain: the Foundation has not yet published a detailed post-incident report clarifying how exactly the script was executed and whether the execution was accidental, the result of a test, or the result of a compromised account.

Why this incident should concern us: beyond vandalism, such a worm has serious safety implications. It can serve as a vector to steal session tokens, perform actions on behalf of affected users, enter links or scripts that redirect to external servers for tracking or loading malware, and undermine confidence in project content. In addition, Wikipedia's distributed and open nature complicates automatic defense measures: many protections are built on trust between editors and in manual controls that require hours of human work.

Also relevant is the fact that the script housed code that linked it to previous campaigns, suggesting that it was not an harmless experiment but a pattern that has been seen before in the wiki ecosystem, according to reports that have traced similar scripts in other incidents.

What users can do now: if you have recently edited Wikimedia wikis and risk uploading the script, check your user page (especiallyUser: Your Name / common.js), removes any suspicious code and restores official scripts from trusted copies. Consider changing passwords and enabling two factors authentication when available. MediaWiki's technical documentation on user JavaScript is a good starting point to understand which files can be run on your browser: Manual: JavaScript (MediaWiki).

For the community and software maintainers, the episode should promote a deep reflection on the need for additional controls around the pages that run code on the editors' browsers: mandatory review of changes in global scripts, better telemetry to detect unusual loads, and stricter processes to run and test scripts in isolated environments before activating them live.

Transparency and outstanding lessons: the immediate technical response stopped the spread, but the absence of a full technical report makes it difficult to know whether there was unauthorized access to staff accounts, whether there is a lack of improvement of internal permissions and test processes, or whether there are vulnerabilities in editing tools that need to be fixed. The community deserves a public and documented investigation that explains the root causes and the proposed corrective measures. In the meantime, tools from third parties and specialized media such as BleepingComputer have published preliminary analyses that help contextualize the attack, and the incident record in Phabicator serves as a primary source for follow-up by technicians and volunteers.

This incident recalls that, in large-scale open and collaborative projects, security is not only the responsibility of managers but a collective effort: clear protocols for internal testing, code audits, response procedures and transparent communication are essential components. The community, developers and the Foundation must work together to close gaps and restore confidence.

If you participate as an editor in any Wikimedia wiki and detect strange behaviors - unexpected readdresses, scripts hidden on your user pages, unauthorized mass editions -, report it immediately on community technical support channels (e.g., Village Pump (technical)) and follows the official guidelines published by the Foundation. To follow the investigation and official announcements, check the follow-up at Phabicator and the status page of Wikimedia in status.wikimedia.org.

History does not end with the elimination of the code: the post-incident report, the concrete measures taken by the Foundation and how security practices will evolve on one of the most visited collaborative platforms on the planet. Meanwhile, the lesson is clear: on the open web, trust must be accompanied by technical controls and processes that minimize the impact of failures and bad actors.