Wikipédia brièvement passée en mode lecture seule après une fuite massive de comptes administrateur, puis rétablie

• Selon la page d’état de la Wikimedia Foundation, plusieurs services wiki, dont Wikipédia, sont brièvement passés en mode lecture seule le 5 mars 2026
• L’incident a commencé par des problèmes d’accès aux wikis, puis a évolué vers une phase où les fonctions d’édition étaient limitées
• La cause n’a pas été précisée, mais le problème a été identifié puis une correction a été déployée, tandis que certaines fonctions restaient encore désactivées
• Le 6 mars, les fonctions de lecture et d’écriture ont été rétablies, et la plupart des fonctionnalités des scripts utilisateur ont également été réactivées
• Wikimedia poursuit ensuite des vérifications de stabilité via une surveillance continue

---

Vue d’ensemble de l’état des systèmes Wikimedia

• La page d’état indique que tous les systèmes fonctionnent normalement (All Systems Operational)
  • Les fonctions de lecture et d’édition sont toutes deux indiquées comme Operational
  • Les métriques affichent 131
    302 requêtes par seconde, 0,08 erreur de connexion signalée par les utilisateurs, 1,27 réponse d’erreur wiki, un temps de réponse moyen de 0,20 seconde et 11,4 éditions réussies

Incident de mode lecture seule des wikis des 5 et 6 mars 2026

• À partir du 5 mars à 15:36 UTC, des problèmes d’accès à certains wikis ont été signalés
  • À 16:11 UTC, le problème a été reconnu et le travail de correction a commencé
  • À 17:09 UTC, le statut indiquait que la cause du problème avait été identifiée et que la correction était en cours
  • À 17:36 UTC, le mode lecture-écriture a été rétabli, bien que certaines fonctions restent encore désactivées
  • À 18:36 UTC, l’incident est passé en phase de surveillance après correction
• Le 6 mars à 00:05 UTC, l’incident était toujours signalé comme en cours de surveillance
  • Il a ensuite été marqué comme résolu (Resolved) avec le message : « les wikis sont restés en mode lecture-écriture pendant plusieurs heures et la plupart des fonctionnalités des scripts utilisateur ont été restaurées »

Autres incidents liés au début mars 2026

• Le 3 mars, un ralentissement des éditions dû à un problème de serveur de base de données s’est produit, puis a été résolu le jour même
  • Problème identifié à 10:09 UTC, correction terminée et surveillance lancée à 10:17 UTC, retour à la normale à 10:24 UTC
• Les 25 et 26 février, une dégradation des performances d’accès aux wikis a été signalée, puis corrigée avant retour à la normale
• Le 20 février, un retard de connexion en Europe s’est produit ; après identification de la cause, correction et surveillance, l’incident a été résolu

Fonctions d’abonnement et d’alerte

• Les utilisateurs peuvent recevoir des notifications d’incident, de mise à jour et de résolution via e-mail, Slack, Webhook et flux Atom/RSS
• Les abonnements par e-mail sont protégés par une authentification OTP et reCAPTCHA
• Les abonnements Slack sont opérés conformément aux conditions d’utilisation et à la politique de confidentialité d’Atlassian Cloud

Résumé

• Wikimedia a connu plusieurs interruptions des fonctions d’édition et dégradations de performances au début du mois de mars, mais toutes ont été rétablies
• Le passage en mode lecture seule des 5 et 6 mars a été l’incident le plus important, et la plupart des fonctions sont revenues à la normale après correction
• Tous les systèmes sont actuellement maintenus dans un état de fonctionnement normal

[GN⁺]

Réactions sur Hacker News

• D’après le ticket Phabricator public, un ingénieur sécurité de la Wikimedia Foundation a chargé au hasard des scripts utilisateurs pour faire des tests
  L’un d’eux était un script malveillant de ruwiki vieux de deux ans, qui s’est injecté dans le JS global, s’est propagé rapidement et a causé des dégâts
  La situation a finalement été jugée assez grave pour faire passer l’ensemble du wiki en mode lecture seule

  • Le plus choquant, c’est que l’erreur vienne d’un ingénieur sécurité
  • Au début, on croyait qu’un attaquant était actif en ce moment, mais une fois compris qu’il s’agissait d’un ancien script malveillant, la résolution est devenue plus simple
    Il suffisait d’utiliser une regex pour détecter le script concerné et de restaurer les pages infectées vers leur version précédente
  • C’est presque un cas à la ver Samy
  • Difficile de croire qu’une organisation de 300 millions de dollars puisse faire ce genre d’erreur
  • On imagine bien un échange du style : « Claude, ton script a exécuté du code malveillant ! » « Oui, désolé ! »

• Le mode de fonctionnement de ce ver est intéressant
  Il s’injecte dans Common.js et User:Common.js de MediaWiki pour maintenir une infection globale, et masque ses traces d’infection avec jQuery
  Il vandalise 20 documents aléatoires et, s’il infecte un compte administrateur, il supprime des documents via la fonction Special:Nuke

  • Cela ressemble surtout à une motivation de type « regardez combien de chaos je peux provoquer »
  • Le domaine basemetrika.ru n’existe pas. Il renvoie une réponse NXDomain
  • Il semble tenter du XSS, mais le code est en pratique inefficace, donc aucun chargement externe n’a lieu
  • Certains pensent qu’un ver aussi sophistiqué a peut-être été conçu par une IA

• Certains disaient que, puisque la base de données elle-même servait de vecteur d’infection, le nettoyage allait être un cauchemar de forensic numérique
  Mais il ne s’agissait pas d’une compromission avec privilèges root, et avec des sauvegardes, une restauration semblait possible

  • Même si quelques jours d’éditions disparaissaient, ce serait supportable à l’échelle de l’ensemble de Wikipedia
  • En pratique, il n’y a pas eu de rollback de base de données, le traitement s’est fait avec les outils classiques de révocation wiki, et seul le site Meta a été touché, pas le cœur de Wikipedia

• Selon l’enquête de la communauté du wiki russe, il semble que le même code que celui utilisé lors d’une attaque de vandalisme contre des wikis alternatifs russophones en 2023 ait encore été utilisé ici
  Le script en question était test.js, créé par l’utilisateur ruwiki Ololoshka562,
  et il est supposé avoir été exécuté quand l’employé WMF sbassett l’a chargé pendant un test

  • L’an dernier déjà, ruwiki avait subi un vandalisme massif selon une méthode similaire

• Cela ressemble à un ancien ver XSS
  Certains trouvent depuis longtemps dangereuse l’architecture de MediaWiki qui autorise les utilisateurs à injecter du JavaScript

  • Ce qui étonne, c’est qu’un tel XSS n’ait pas encore servi à des attaques comme le vol de mots de passe
    Avec une faille d’autocomplétion du navigateur comme dans cet article, cela aurait pu être bien plus grave

• Même si l’on a des griefs contre Wikipedia, cela ne justifie en rien du harcèlement ou du stalking en prenant cet incident comme prétexte

• D’après un ami éditeur sur le wiki, cet incident ressemble à un piratage par cross-site scripting (XSS)
  Le code parti d’une page utilisateur du wiki russe s’est propagé via le common.js de Meta,
  et on voyait les opérateurs faire des révocations manuelles sur la page Recent Changes

  • Cela ressemble à une « attaque venue de Russie », mais il est très facile d’usurper ce type d’origine
  • Un autre utilisateur estime toutefois qu’il s’agit probablement d’une variante de l’ancien outil de piratage russe « woodpecker »

• Pour plus de contexte, il y a aussi le forum Wikipediocracy,
  la discussion Village Pump,
  et le méga-thread Reddit
  Le payload en question peut être consulté à ce lien

  • La version Web Archive peut être consultée en sécurité
  • Certains liens ne s’ouvrent pas faute de droits d’accès

• En réalité, ce genre d’incident n’était qu’une question de temps
  Wikipedia a longtemps montré une attitude trop désinvolte vis-à-vis de la sécurité
  Avec le seul droit d’« administrateur d’interface », on peut modifier le JS/CSS global, et la 2FA n’a été introduite que récemment
  En plus, beaucoup d’utilisateurs utilisent des scripts utilisateurs non vérifiés
  Cette architecture est en elle-même un cauchemar de sécurité, et c’est probablement pour cela que les scripts utilisateurs ont été désactivés globalement après cet incident

  • Par le passé, même la page d’accueil a déjà été supprimée (lien)
  • Il y a actuellement environ 137 administrateurs d’interface, dont la plupart sont des employés de Wikimedia, donc des personnes au moins vérifiées
  • Comme Internet devient de plus en plus hostile, certains estiment qu’il faut des dons ou du soutien technique pour résoudre ce type de problème
  • Les scripts utilisateurs via des extensions de navigateur (TamperMonkey, etc.) existent toujours, donc un blocage total reste impossible
  • En pratique, seuls 15 administrateurs d’interface sont actifs sur le wiki anglophone (référence)

• On voit aussi passer des blagues disant que, maintenant que l’IA a entièrement aspiré Wikipedia, plus personne n’utilise directement Wikipedia de toute façon