Wikipedia was in read-only mode following mass admin account compromise

Original Article ↗ Hacker News Discussion ↗

Wikipedia was briefly placed in read-only mode after a malicious JavaScript “worm” spread through its MediaWiki user script system, triggering mass deletions and vandalism once it reached highly privileged accounts. The incident appears to have started when a Wikimedia Foundation security engineer, testing at scale, inadvertently loaded a dormant, two‑year‑old Russian‑language user script into global JavaScript that runs for all users, allowing the code to propagate rapidly. Commenters focus on how this reveals long‑standing security weaknesses in Wikipedia’s interface‑editing model, the risks of powerful client‑side scripting, and the need for stronger controls, review processes, and infrastructure investment despite Wikipedia’s substantial funding.

Incident and Worm Behavior

  • Discussion centers on a cross‑site scripting (XSS) “worm” that spread via MediaWiki JavaScript, leading to wikis being set read‑only.
  • The script reportedly:
    • Injected itself into MediaWiki:Common.js (global JS) and user JS pages to persist and propagate.
    • Hid UI clues via jQuery.
    • Vandalized random articles with a large image and attempted to load another script from basemetrika.ru.
    • On admin accounts, used bulk tools (Special:Nuke, delete via Special:Random) to mass‑delete pages.
  • Later comments claim the basemetrika.ru payload wouldn’t actually execute due to how it was embedded, and the domain is now defunct / re‑registered.

Cause and Vector

  • A public bug tracker entry and later WMF statement describe the root cause: a highly privileged Foundation staff account testing API limits by loading many existing user scripts, including an old malicious script from Russian Wikipedia.
  • This was not a new exploit of MediaWiki core but effectively “testing in prod” with random user JS under a powerful account.

MediaWiki Security Model and Permissions

  • Many criticize the long‑standing ability for “interface administrators” and global staff to edit sitewide JS/CSS with no mandatory review workflow.
  • Some note the number of such users is small, but others argue any direct edit to global JS should require code review and safer deployment mechanisms.
  • Wikipedia’s unsandboxed “user script” ecosystem is called a “security nightmare,” yet also recognized as essential tooling relied on by power users.

JavaScript and Client‑Side Debate

  • Several participants argue that heavy client‑side JS and executable user scripts are inherently dangerous, advocating:
    • Default JS‑off browsing.
    • Minimal JS or JS‑free versions of Wikipedia.
  • Others reply that Wikipedia already largely works without JS, and that native apps or plugin ecosystems are not inherently safer.

2FA, Backups, and Cleanup

  • Some suggest stronger or more frequent 2FA prompts for JS edits; others counter that this wouldn’t stop propagation once one privileged session is compromised.
  • Extensive debate on recovery: snapshot frequency, rolling back vs. reverting only malicious edits, and avoiding loss of legitimate edits.
  • One comment says no database rollback occurred; reversions used standard wiki tools.

Organizational and Funding Critiques

  • Critiques that Wikimedia underinvests in security despite large budgets; calls for more modern practices (code signing, supply‑chain controls, stricter admin security).
  • One commenter falsely claims Wikimedia is a for‑profit with shareholders; others strongly refute this as “total horseshit.”

Broader Implications

  • Concerns about:
    • Wikipedia’s centrality to shared knowledge and what a major outage or compromise implies.
    • Propagation of poisoned content into LLM training pipelines (raised but left unresolved).
  • Some see the worm as “old‑school vandalism” rather than monetized crime, but still a wake‑up call for governance and security culture.