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

Original Article ↗ Hacker News Discussion ↗

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.