Die Burst-Statistics-Lücke CVE-2026-8181 erlaubt unauthentifizierten Angreifern, sich als WordPress-Admin auszugeben. Wordfence hat in den ersten 24 Stunden nach Disclosure mehr als 7.400 Exploit-Versuche blockiert. Für deutsche Site-Betreiber wird die akute Frage zur Pflicht: Wer hat sich seit dem 23. April als Administrator eingetragen?
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Der MainWP-Auth-Bug sitzt im Authentifizierungs-Proxy des Burst-Statistics-Plugins. Ein fehlerhafter Return-Value-Check lässt Angreifer mit einem präparierten Basic-Auth-Header die REST-API als beliebiger Admin nutzen. Der Angreifer muss nur den Benutzernamen kennen, das Passwort ist beliebig.
Ein erfolgreicher Angriff bedeutet vollen Adminzugriff ohne weitere Hürden.
Das Wichtigste in Kürze
- Burst Statistics 3.4.2 schließt CVE-2026-8181, alle Vorgänger-Versionen sind betroffen
- Unauthentifizierte Admin-Impersonation per Basic-Auth-Header
- Wordfence blockte 7.400 Exploit-Versuche binnen 24 Stunden
- Sofortmaßnahmen: Update, Admin-Passwörter rotieren, neue Admin-Accounts prüfen
Wie funktioniert der Angriff?
Der Code-Fehler ist erschreckend simpel. Der Authentifizierungs-Proxy prüft, ob ein Auth-Vorgang erfolgreich war, vergleicht aber das falsche Ergebnis. Statt zu prüfen, ob die Anmeldung tatsächlich geklappt hat, fragt der Code ab, ob die Funktion überhaupt aufgerufen werden konnte. Ein leerer Aufruf führt damit zur erfolgreichen Authentifizierung.
Die praktische Konsequenz ist katastrophal. Angreifer scannen automatisiert WordPress-Sites nach installiertem Burst Statistics. Wenn gefunden, schicken sie einen REST-API-Request mit dem Header `Authorization: Basic admin:irgendetwas`. Der Server akzeptiert die Anfrage und liefert vollen Adminzugriff. Damit lassen sich neue Konten anlegen, Plugins ändern oder Datenbanken auslesen.
Username genügt, Passwort egal. Das ist kein Bug mehr, das ist ein Scheunentor. Wer Burst Statistics nutzt, sollte heute updaten und morgen die Admin-Liste prüfen. Übermorgen ist zu spät.
— Michael Dobler, Herausgeber Dr. Web
Wer ist betroffen?
Die Verbreitung von Burst Statistics liegt bei rund 200.000 aktiven Installationen. Das Plugin ist beliebt, weil es DSGVO-konforme Analytics ohne Cookie-Banner liefert. Genau in der DACH-Region läuft es deshalb häufig auf Sites, die strenge Datenschutzanforderungen erfüllen müssen. Der Charme der Cookie-Freiheit wird damit zum Risiko-Faktor.
Betroffen sind alle Versionen unter 3.4.2. Wer die automatischen Updates eingeschaltet hat, ist seit Mitte Mai geschützt. Wer manuell aktualisiert, sollte spätestens jetzt nachziehen. Hosting-Anbieter mit Managed-WordPress-Diensten haben das Update meist eingespielt, der Site-Betreiber sollte das aber unbedingt verifizieren.
Welche Sofortmaßnahmen sind nötig?
Drei Schritte stehen jetzt im Vordergrund. Zunächst das Update auf Burst Statistics 3.4.2 oder neuer. Parallel die Passwort-Rotation für alle Admin-Konten, weil ein erfolgreicher Angriff Adminzugriff hinterlassen haben kann. Schließlich der Audit der Nutzerverwaltung: Wurden seit dem 23. April neue Admin-Accounts angelegt? Wenn ja, von wem und mit welcher E-Mail-Adresse?
Ein Forensik-Schritt lohnt sich auf Sites mit hohem Traffic. Server-Logs nach REST-API-Calls auf `/wp-json/burst/*` durchsuchen und auf ungewöhnliche User-Agents oder IP-Adressen achten. Wordfence und Patchstack bieten dafür automatisierte Werkzeuge. Wer eigene Schreibrechte für Plugins eingeschränkt hat, gewinnt zusätzliche Resilienz, weil ein kompromittierter Admin kein Plugin mehr unbemerkt installieren kann.
[kadence_element id="494621"]Was lehrt die Lücke strukturell?
Authentifizierungs-Proxys gehören zu den fehleranfälligsten Komponenten im WordPress-Ökosystem. Drei der vier kritischen Mai-Lücken sind Auth-Bugs. Das Muster zeigt, wo Pluginsicherheit verbessert werden muss. AI-gestützte Code-Review-Tools finden solche Bugs in Sekunden, die manuelle Prüfung dauert Wochen. KI als Sicherheitswerkzeug wird damit zum produktiven Bestandteil der Plugin-Entwicklung.
Für deutsche WordPress-Agenturen ergibt sich daraus eine strategische Aufgabe. Kundenverträge sollten klare Update-SLAs enthalten, Notfallpläne für kritische Disclosures vorab definieren und Wordfence oder Patchstack als virtuelle Schutzschicht einplanen. Mehr Hintergrund zur Lücke dokumentiert das Wordfence-Blog.
Mehr Newshunger?
