Security News Wikipedia hit by self-propagating JavaScript worm that vandalized pages

[Parkinsond]

Content source

https://www.bleepingcomputer.com/news/security/wikipedia-hit-by-self-propagating-javascript-worm-that-vandalized-pages/

The Wikimedia Foundation suffered a security incident today after a self-propagating JavaScript worm began vandalizing pages and modifying user scripts across multiple wikis.

Users noticed a large number of automated edits adding hidden scripts and vandalism to random pages.

Wikimedia engineers temporarily restricted editing across projects while they investigated the attack and began reverting changes.

It appears the incident started after a malicious script hosted on Russian Wikipedia was executed, causing a global JavaScript script on Wikipedia to be modified with malicious code.

Wikipedia hit by self-propagating JavaScript worm that vandalized pages

The Wikimedia Foundation suffered a security incident today after a self-propagating JavaScript worm began vandalizing pages and modifying user scripts across multiple wikis.

www.bleepingcomputer.com

 

[Divergent]

Executive Summary

Confirmed Facts
A self-propagating JavaScript worm executed within the Wikimedia Foundation's environment, modifying approximately 3,996 pages and overwriting the common.js files of roughly 85 users. The attack utilized an external script (basemetrika.ru/s/e41) to perform automated edits and deploy visual vandalism ([[File:Woodpecker10.jpg|5000px]]).

Assessment
The incident represents a severe Application-Layer (Layer 7) logic abuse, though it poses zero direct infection threat to underlying endpoint operating systems.

Technical Analysis & Remediation

MITRE ATT&CK Mapping

T1059.007
(Command and Scripting Interpreter: JavaScript)

T1189
(Drive-by Compromise)

T1098
(Account Manipulation - via hijacked session privileges)

CVE Profile
Feature Abuse / N/A [CISA KEV Status: Inactive]

Telemetry

Source Script
User:Ololoshka562/test.js

External Payload Domain
hxxps://basemetrika[.]ru/s/e41

Vandalism Artifact
[[File:Woodpecker10.jpg|5000px]]

Targeted Application Files
MediaWiki:Common.js, User:<username>/common.js

Constraint
Because no endpoint binary analysis is applicable, the structure resembles a classic Cross-Site Scripting (XSS) worm (similar to the historic Samy worm), constrained entirely to the browser's Document Object Model (DOM) and session cookies.

Remediation - THE ENTERPRISE TRACK (NIST SP 800-61r3 / CSF 2.0)

GOVERN (GV) – Crisis Management & Oversight

Command
Establish a policy review for web application administrators regarding the testing of untrusted, user-submitted code in production environments.

DETECT (DE) – Monitoring & Analysis

Command
Deploy SIEM/Proxy hunting queries for network traffic attempting to resolve or pull resources from basemetrika[.]ru.

Command
Monitor web application logs for anomalous spikes in Special:Random requests.

RESPOND (RS) – Mitigation & Containment

Command
Temporarily restrict global editing privileges across affected Wiki projects.

Command
Force session invalidation (logout) for all currently active administrative and standard user accounts.

RECOVER (RC) – Restoration & Trust

Command
Execute database rollbacks to purge malicious modifications to MediaWiki:Common.js and individual user common.js files.

Command
Suppress malicious page revisions from public viewing history.

IDENTIFY & PROTECT (ID/PR) – The Feedback Loop

Command
Implement Content Security Policy (CSP) headers to restrict external script execution to trusted domains only.

Remediation - THE HOME USER TRACK (Safety Focus)

Priority 1: Safety

Command
Clear all browser cache, cookies, and active session data for any Wikimedia/Wikipedia domains. (Internet disconnection is not required, as the Environmental Reality Check confirms this is not an OS-level infection).

Priority 2: Identity

Command
Log back into your account and verify that your personal User:<username>/common.js file does not contain unauthorized script tags.

Priority 3: Persistence

Command
Check browser extensions for any unauthorized additions, though this specific attack relies on server-side stored scripts rather than local endpoint persistence.

Hardening & References

Baseline
CIS Benchmarks for Web Browsers (Google Chrome / Mozilla Firefox) - specifically enforcing strict site isolation and cookie security.

Framework
NIST CSF 2.0 / SP 800-61r3.

Source

BleepingComputer

 

[Jonny Quest]

@Divergent thanks, as this is what I was wondering about. (I don't have an account that I login with them)

Priority 1: Safety
Command
Clear all browser cache, cookies, and active session data for any Wikimedia/Wikipedia domains. (Internet disconnection is not required, as the Environmental Reality Check confirms this is not an OS-level infection).

 

[Divergent]

@Divergent thanks, as this is what I was wondering about. (I don't have an account that I login with them)

The attack requires the presence of an active, authenticated login cookie to execute state-changing actions (editing pages) via the MediaWiki API.

 

[Wrecker4923]

My synopsis is: a privileged (employee) account loads unknown JavaScript code, which results in writing to a restricted text file (global JavaScript code) that all editors load. This leads to further writing to restricted text files (project-specific JavaScript files for privileged accounts and account-specific JavaScript files).

It looks like Wikimedia needs to control those JavaScript files as multi-party-approved source codes, rather than as restricted text files loaded as source codes that become "production" immediately upon save. This might take a while.

Meanwhile, besides clearing the cache, the editors may want to put on their watchlist the source files they depend on, including:

1. MediaWiki:Common.js
2. User:<username>/common.js
3. Any other JavaScript files their account JavaScript file loads from.

Wikimedia also has accumulated technical debt by allowing an account known to be a potential source of another attack to remain in the system, a debt that was collected. This resulted in recoverable damage and reputation damage, and expose a medium-long term attack surface. According to a Russian website mentioned in the BC article, the employee in question triggered this event due to incompetence (rather than malice), so more organizational and procedural controls may be needed as well. Also, according to the Russian website, prior similar attacks on other encyclopedias were irrecoverable for those sites.

 

[Wrecker4923]

Wikimedia Foundation/Product and Technology/Product Safety and Integrity/March 2026 User Script Incident - Meta-Wiki

meta.wikimedia.org

Earlier today (March 5, 2026), Wikimedia Foundation staff were conducting a security review of user-authored code on Wikipedia. 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.

Used text according to the Creative Commons Attribution-ShareAlike License; .

 

[Khushal]

WIKIPEDIA WORM Hashes if anyone interested: 4cbd2d697fe52b159d4adb4629c0c803 d2c72104212b805ce981a097eb424c52 fcfcf495d9d208a3b3bd426b701d0ac0.