Wikipedia wechselte nach massenhaftem Leak von Administratorkonten in den Nur-Lesen-Modus und wurde anschließend wiederhergestellt

• Laut der Statusseite der Wikimedia Foundation wurden am 5. März 2026 mehrere Wiki-Dienste, darunter Wikipedia, vorübergehend in den Nur-Lesen-Modus versetzt
• Es begann mit Störungen beim Zugriff auf Wikis und ging anschließend in eine Phase über, in der Bearbeitungsfunktionen eingeschränkt waren
• Die Ursache wurde nicht ausdrücklich genannt, doch nach Identifizierung des Problems liefen Korrekturarbeiten, und einige Funktionen waren weiterhin deaktiviert
• Am 6. März wurden die Lese- und Schreibfunktionen wiederhergestellt, und auch die meisten Benutzerskript-Funktionen wurden erneut aktiviert
• Wikimedia führt anschließend weitere Überwachung zur Stabilitätsprüfung durch

---

Überblick über den Wikimedia-Systemstatus

• Auf der Statusseite wird angezeigt, dass alle Systeme normal funktionieren (All Systems Operational)
  • Sowohl Lese- als auch Bearbeitungsfunktionen sind als Operational gekennzeichnet
  • Erfasst wurden 131.002 Anfragen pro Sekunde, 0,08 gemeldete Verbindungsfehler durch Nutzer, 1,27 Wiki-Fehlerantworten, eine durchschnittliche Antwortzeit von 0,20 Sekunden und 11,4 erfolgreiche Bearbeitungen

Vorfall zum Wiki-Nur-Lesen-Modus am 5.–6. März 2026

• Ab dem 5. März um 15:36 UTC wurden Probleme beim Zugriff auf einige Wikis gemeldet
  • Um 16:11 UTC wurde das Problem erkannt und mit den Korrekturarbeiten begonnen
  • Um 17:09 UTC wurde angezeigt, dass die Ursache identifiziert wurde und an der Behebung gearbeitet wird
  • Um 17:36 UTC wurden der Lese-Schreib-Modus wiederhergestellt, einige Funktionen blieben jedoch weiterhin deaktiviert
  • Um 18:36 UTC wechselte der Status nach Abschluss der Behebung in die Überwachungsphase
• Am 6. März um 00:05 UTC wurde gemeldet, dass weiter überwacht wird
  • Danach wurde der Vorfall als gelöst (Resolved) markiert mit dem Hinweis, dass „das Wiki mehrere Stunden im Lese-Schreib-Modus geblieben ist und die meisten Benutzerskript-Funktionen wiederhergestellt wurden“

Weitere verwandte Vorfälle Anfang März 2026

• Am 3. März kam es aufgrund eines Problems mit dem Datenbankserver zu Verzögerungen bei Bearbeitungen, das noch am selben Tag gelöst wurde
  • Um 10:09 UTC wurde das Problem identifiziert, um 10:17 UTC war die Behebung abgeschlossen und die Überwachung begann, um 10:24 UTC war der Normalzustand wiederhergestellt
• Am 25.–26. Februar wurde eine verschlechterte Zugriffsleistung auf Wikis gemeldet, die jeweils nach einer Behebung wieder normalisiert wurde
• Am 20. Februar kam es in Europa zu Zugriffsverzögerungen; nach Identifizierung der Ursache wurde der Vorfall nach Behebung und Überwachung gelöst

Abonnement- und Benachrichtigungsfunktionen

• Nutzer können über E-Mail, Slack, Webhook und Atom/RSS-Feeds Benachrichtigungen über Vorfälle, Updates und deren Behebung erhalten
• Bei E-Mail-Abonnements werden OTP-Verifizierung und reCAPTCHA-Schutz angewendet
• Slack-Abonnements werden gemäß den Atlassian Cloud-Nutzungsbedingungen und der Datenschutzrichtlinie betrieben

Zusammenfassung

• Wikimedia hatte Anfang März mehrfach mit Ausfällen von Bearbeitungsfunktionen und Leistungseinbrüchen zu kämpfen, die jedoch alle behoben wurden
• Die Umschaltung in den Nur-Lesen-Modus am 5.–6. März war der größte Vorfall; nach der Behebung normalisierten sich die meisten Funktionen wieder
• Derzeit bleiben alle Systeme im Normalbetrieb

[GN⁺]

Hacker-News-Kommentare

• Das öffentlich einsehbare Phabricator-Ticket zeigt, dass ein Security Engineer der Wikimedia Foundation zu Testzwecken zufällige Benutzerskripte geladen hat
  Eines davon war ein zwei Jahre altes bösartiges ruwiki-Skript, das sich in globales JS injizierte, sich schnell verbreitete und Schaden anrichtete
  Am Ende war der Vorfall so schwerwiegend, dass das gesamte Wiki in den Nur-Lese-Modus versetzt wurde

  • Besonders schockierend ist, dass diesen Fehler ausgerechnet ein Security Engineer gemacht hat
  • Zunächst dachte man, es gebe einen aktuellen Angreifer, aber als klar wurde, dass es sich um ein altes bösartiges Skript handelte, wurde die Behebung einfach
    Man musste nur mit einem regulären Ausdruck nach dem Skript suchen und infizierte Seiten auf frühere Versionen zurücksetzen
  • Das wirkt fast wie ein Fall ähnlich dem Samy-Wurm
  • Kaum zu glauben, dass eine Organisation mit 300 Millionen Dollar Budget so einen Fehler macht
  • Man kann sich fast einen Dialog vorstellen wie: „Claude, dein Skript hat Schadcode ausgeführt!“ „Stimmt, tut mir leid!“

• Die Funktionsweise dieses Wurms ist interessant
  Er injiziert sich in MediaWikis Common.js und User:Common.js, hält so eine globale Infektion aufrecht und verbirgt Spuren der Infektion mit jQuery
  Er vandalisiert 20 zufällige Dokumente und löscht bei einer Infektion von Admin-Konten mit der Funktion Special:Nuke Dokumente

  • Es wirkt wie eine simple Motivation nach dem Muster: „Seht, wie viel Chaos ich anrichten kann“
  • Die Domain basemetrika.ru existiert nicht. Es kommt eine NXDomain-Antwort zurück
  • Es sieht nach einem Versuch von XSS aus, aber der Code ist tatsächlich wirkungslos, daher findet kein externer Load statt
  • Manche halten es für möglich, dass ein so ausgefeilter Wurm von KI entworfen wurde

• Es hieß, dass die Datenbank selbst der Infektionsvektor sei, weshalb die Aufräumarbeiten ein Albtraum der digitalen Forensik würden
  Allerdings wurde kein Root-Zugriff erlangt, und mit Backups scheint eine Wiederherstellung möglich

  • Selbst wenn ein paar Tage an Bearbeitungen verloren gingen, wäre das im Maßstab von Wikipedia verkraftbar
  • Tatsächlich wurde nicht die DB zurückgerollt, sondern mit den üblichen Wiki-Revert-Tools gearbeitet, und betroffen war nur die Meta-Site, nicht Wikipedia selbst

• Laut Untersuchungen aus der russischen Wiki-Community scheint derselbe Code verwendet worden zu sein, der 2023 bei Vandalismusangriffen auf russischsprachige Alternativ-Wikis eingesetzt wurde
  Das Skript war test.js des ruwiki-Nutzers Ololoshka562,
  und es wird vermutet, dass der WMF-Mitarbeiter sbassett es beim Testen geladen und dadurch ausgeführt hat

  • Bereits im vergangenen Jahr wurde ruwiki auf ähnliche Weise massiv beschädigt

• Das sieht nach einem alten XSS-Wurm aus
  Ich hielt die Struktur von MediaWiki, die Benutzern das Einfügen von JavaScript erlaubt, schon lange für riskant

  • Erstaunlich ist, dass solches XSS bisher offenbar nicht für Angriffe wie Passwortdiebstahl genutzt wurde
    Mit Browser-Autofill-Schwachstellen wie in diesem Artikel hätte das viel gravierender werden können

• Selbst wenn man mit Wikipedia unzufrieden ist, rechtfertigt dieser Vorfall Belästigung oder Stalking nicht

• Laut einem befreundeten Wiki-Editor wirkt der Vorfall wie ein Cross-Site-Scripting-(XSS)-Hack
  Der Code begann auf einer Benutzerseite der russischsprachigen Wikipedia und verbreitete sich über common.js von Meta,
  und man konnte auf der Seite Recent Changes sehen, wie Betreiber die Änderungen manuell zurücksetzten

  • Es wirkt wie ein „Angriff aus Russland“, aber die Herkunft auf diese Weise zu fälschen ist sehr einfach
  • Ein anderer Nutzer hält es jedoch für wahrscheinlich, dass der Code eine Variante des alten russischen Hacking-Tools „woodpecker“ ist

• Als zusätzlicher Kontext wurden das Wikipediocracy-Forum,
  die Village-Pump-Diskussion
  und ein Reddit-Megathread genannt
  Die fragliche Payload lässt sich unter diesem Link einsehen

  • Die Web-Archive-Version kann man gefahrlos ansehen
  • Einige Links lassen sich wegen fehlender Zugriffsrechte nicht öffnen

• Eigentlich war so etwas nur eine Frage der Zeit
  Wikipedia ist mit Sicherheit lange zu sorglos umgegangen
  Mit den Rechten eines „Interface-Administrators“ kann man globales JS/CSS ändern, und 2FA wurde erst vor Kurzem eingeführt
  Außerdem verwenden viele Nutzer nicht verifizierte Benutzerskripte
  Diese Struktur an sich ist ein Sicherheitsalbtraum, und vermutlich wurden Benutzerskripte deshalb nach diesem Vorfall global deaktiviert

  • Früher wurde sogar schon einmal die Hauptseite gelöscht (Link)
  • Derzeit gibt es ungefähr 137 Interface-Administratoren, die meisten davon Wikimedia-Mitarbeiter und damit zumindest überprüfte Personen
  • Da das Internet immer feindseliger wird, fühlt es sich so an, als brauche es Spenden oder technische Unterstützung, um solche Probleme zu lösen
  • Benutzerskripte über Browser-Erweiterungen wie TamperMonkey existieren weiterhin, eine vollständige Sperre ist also unmöglich
  • In der englischsprachigen Wikipedia sind tatsächlich nur 15 Interface-Administratoren aktiv (Referenz)

• Es gab auch den scherzhaften Kommentar, dass jetzt ohnehin niemand Wikipedia direkt nutzt, weil KI bereits alles von Wikipedia abgeschöpft hat