Un code JavaScript auto-propagateur a perturbé plusieurs projets Wikimedia, en modifiant des scripts utilisateurs et en corrompant des pages Meta-Wiki, avant d’être neutralisé par les équipes techniques.

La Fondation Wikimedia a été confrontée à un incident de sécurité impliquant un ver JavaScript capable de se répliquer via les mécanismes de personnalisation de MediaWiki. Selon les éléments rendus publics, le code malveillant a touché des scripts utilisateurs, altéré des pages Meta-Wiki et conduit les ingénieurs à suspendre temporairement les modifications sur l’ensemble des projets par mesure de précaution. L’épisode, resté actif 23 minutes d’après la Fondation, n’aurait pas affecté Wikipédia elle-même ni provoqué de fuite de données. L’affaire met néanmoins en lumière un point sensible : l’exécution de code utilisateur dans l’environnement d’édition, au croisement de la sécurité applicative, des privilèges éditoriaux et de la gouvernance technique des plateformes collaboratives.

Un déclenchement via les scripts utilisateurs de MediaWiki

L’alerte est venue de contributeurs qui ont signalé sur Village Pump, l’espace d’assistance technique, des modifications automatisées massives. D’après leurs constats, des scripts cachés et du contenu indésirable avaient été ajoutés à des pages choisies de manière aléatoire. Face à cette activité anormale, la Fondation Wikimedia a restreint temporairement les modifications sur tous les projets, le temps de contenir l’incident.

Les premiers éléments techniques pointent vers un script malveillant hébergé sur Wikipédia en russe, à l’emplacement User:Ololoshka562/test.js. Le fichier, mis en ligne pour la première fois en mars 2024, avait déjà été lié à des outils employés lors d’autres attaques visant des projets Wikipédia. D’après les informations issues du suivi Phabricator, l’incident a commencé avec l’exécution de ce script. En examinant l’historique des modifications, les journalistes de Bleeping Computer ont ensuite relevé que ce code avait été lancé la semaine précédente par un employé de Wikimedia dans le cadre de tests portant sur les fonctionnalités liées aux scripts utilisateurs. À ce stade, il n’est pas établi si cette exécution relevait d’un geste intentionnel, d’une erreur de manipulation ou de l’usage d’un compte compromis.

Le fonctionnement du ver reposait sur une mécanique élémentaire, mais redoutablement efficace dans un environnement collaboratif. MediaWiki autorise en effet l’usage de fichiers JavaScript globaux et personnalisés, notamment MediaWiki:Common.js et User:<nom_utilisateur>/common.js. Ces scripts sont exécutés dans le navigateur des éditeurs afin d’adapter l’interface, d’automatiser certaines tâches ou d’ajouter des fonctions sur mesure. Une fois chargé dans le navigateur d’un utilisateur connecté, test.js tentait de modifier deux cibles en parallèle.

Au niveau du compte, il remplaçait common.js par un chargeur chargé d’appeler automatiquement test.js à chaque consultation du wiki. Autrement dit, l’infection persistait dès qu’un utilisateur touché revenait sur la plateforme. Au niveau du site, si la victime disposait de privilèges suffisants, le ver modifiait MediaWiki:Common.js, un fichier global exécuté pour tous les éditeurs concernés. Dans ce scénario, la propagation devenait immédiatement plus large, car le code malveillant s’insérait au cœur même de la couche de personnalisation commune.

Meta-Wiki touché, restauration engagée et audit renforcé

Le ver ne se contentait pas d’assurer sa diffusion. Il appelait aussi une page aléatoire via Special:Random, puis y injectait une image ainsi qu’un chargeur JavaScript invisible. Ce dernier récupérait un script externe depuis le domaine basemetrika[.]ru. Cette dimension externe accroît l’intérêt de l’incident pour les observateurs de la cybersécurité : au-delà d’une simple dégradation interne, le mécanisme ouvrait une chaîne d’exécution capable d’introduire un contenu distant dans des pages du wiki, avec un effet potentiel sur l’intégrité éditoriale et la confiance accordée à l’environnement.

Selon les estimations citées par les journalistes, environ 3 996 pages ont été modifiées, tandis que les fichiers common.js d’environ 85 utilisateurs ont été remplacés. Le volume exact des suppressions de pages n’est pas connu. La Fondation Wikimedia a depuis annulé les modifications apportées à plusieurs fichiers common.js d’utilisateurs. Les pages altérées ont été masquées et n’apparaissent plus dans l’historique des modifications. Après la suppression du code injecté, l’édition a pu reprendre.

La Fondation affirme que le code malveillant n’est resté actif que 23 minutes. Durant cette période, il aurait modifié et supprimé du contenu uniquement sur Meta-Wiki, avant restauration des données. L’organisation précise qu’aucun signe d’attaque visant Wikipédia elle-même n’a été observé et qu’aucune fuite de données n’a été détectée. Dans sa déclaration, elle explique que son personnel menait un audit de sécurité du code utilisateur sur Wikipédia, et que du code jusque-là inactif a été exécuté puis rapidement identifié comme malveillant. Par précaution, la modification sur Wikipédia et sur d’autres projets Wikimedia a été suspendue le temps d’éliminer ce code et de sécuriser l’environnement.

Cet épisode illustre une zone de risque connue des plateformes extensibles : les fonctions de personnalisation, utiles à l’exploitation quotidienne, peuvent aussi devenir des vecteurs de propagation lorsqu’un script hostile bénéficie d’une exécution légitime dans le navigateur d’un utilisateur connecté. Le fait qu’un simple chargement puisse conduire à la réécriture de scripts utilisateurs, puis éventuellement d’un fichier global, montre combien la frontière entre assistance à l’édition et surface d’attaque peut se réduire. Wikimedia indique désormais déployer des mesures de sécurité supplémentaires pour limiter le risque de récidive.

Au-delà du rétablissement du service, l’incident rappelle que la sécurité des plateformes collaboratives dépend aussi du contrôle du code client, des privilèges d’édition et de la capacité à détecter rapidement une propagation interne avant qu’elle ne devienne un problème de gouvernance numérique.