Wikipedia in read-only mode following mass admin account compromise
Wikipedia faced a significant security breach, going into read-only mode after a sophisticated XSS worm compromised admin accounts. This incident exposed foundational vulnerabilities in MediaWiki's architecture, particularly its handling of user-editable JavaScript. Hacker News dove deep into the technical specifics of the attack and debated the long-standing security challenges of such platforms.
The Lowdown
Wikipedia recently experienced a significant security incident, forcing the platform into read-only mode following a widespread compromise of administrator accounts. This was triggered by a sophisticated XSS worm exploiting inherent vulnerabilities in the MediaWiki platform's handling of user-editable JavaScript. The incident prompted swift action from the Wikimedia Foundation and ignited extensive technical discussion on Hacker News.
- The Wikimedia status page confirmed wikis were in read-only mode due to an "Unresolved incident" on March 5, 2026.
- The issue was identified as a mass admin account compromise via a JavaScript worm, and a fix was promptly implemented, restoring read-write functionality, though some features remained disabled.
- The worm specifically injected itself into critical global scripts (
MediaWiki:Common.js) and user-specific scripts (User:Common.js), ensuring widespread propagation. - It employed insidious tactics, such as using jQuery to hide UI elements from infected administrators while silently triggering destructive actions like
Special:Nuketo delete articles. - The worm also reportedly vandalized articles with large images and attempted to inject further XSS scripts from an external, now-defunct, domain (
basemetrika.ru).
This incident underscores the delicate balance between powerful, flexible wiki architectures and the critical need for robust security measures, especially concerning user-controlled executable code within a collaborative environment.
The Gossip
Worm's Wicked Workings
Commenters quickly dissected the XSS worm's payload, describing its mechanics as a "weaponized, highly destructive version of the old MySpace Samy worm." They highlighted its propagation via `MediaWiki:Common.js`, its stealthy use of jQuery to blind administrators, and its destructive actions like mass article deletion via `Special:Nuke` and page vandalism. Many noted the parallels to classic XSS attacks and the inherent dangers of allowing executable JavaScript in user-editable spaces.
Architectural Accountability
A significant thread emerged discussing MediaWiki's long-standing security posture and the Wikimedia community's approach. Critics argued that the incident was "only a matter of time," citing the powerful capabilities of 'interface administrators' to modify global JavaScript without review and the prevalence of unsandboxed, often unmaintained, user scripts. There was a debate on whether this was a vulnerability in MediaWiki itself or a consequence of overly permissive user permissions, with some suggesting a fundamental flaw in the design that allows client-side logic to have such power.
PHP's Persistent Presence
Tangentially, the discussion veered into the programming language PHP, in which MediaWiki is written. Some commenters, recalling historical quirks (like `return flase` evaluating to true in older versions), used the incident to rehash common criticisms of PHP as a source of security issues. Others defended modern PHP, pointing out its significant improvements, performance, and role in powering much of the web, while acknowledging that poor usage or outdated versions can still create vulnerabilities.
Wikimedia's Wealth & Woes
Several commenters questioned Wikimedia Foundation's financial management, given the security breach. They cited the Foundation's substantial revenue and healthy surplus, suggesting that despite being well-funded, resources might not be adequately directed towards core platform security. This led to a discussion about how Wikimedia spends its money, with some pointing out large salaries and donation processing costs compared to internet hosting, and others arguing that a surplus is prudent for long-term stability and that its budget is not excessive compared to other high-traffic sites.
AI's Assault Apprehensions
A speculative mini-discussion considered whether sophisticated worms like this could be designed by AI. While some wouldn't be surprised, others felt the worm's "unusual stylistic choices" suggested human authorship, perhaps with AI assistance, rather than a fully autonomous AI creation.
Basemetrika's Bizarre Blank
The fact that the external domain (`basemetrika.ru`) used by the XSS script was non-existent sparked humorous speculation. Commenters wondered if it was a mistake by the attacker or a deliberate red herring, and playfully suggested what to do with the now-available domain, including injecting silly JavaScript alerts or classic internet memes.