WordPress Core: Race-Condition-Lücke jetzt im CISA-KEV, Patch ist da
CISA führt CVE-2026-119977 im KEV-Katalog. Die WordPress-Lücke erlaubt beim Core-Update Code-Ausführung ohne Login. Fixes gibt es seit 28. Oktober für alle Zweige ab 4.7. Jetzt updaten und Logs prüfen.
Am 3. November 2026 hat die US-Cybersicherheitsbehörde CISA die WordPress-Core-Lücke CVE-2026-119977 in ihren KEV-Katalog aufgenommen. KEV steht für "Known Exploited Vulnerabilities". Dort landen nur Schwachstellen, bei denen CISA Belege für aktive Ausnutzung hat. Vorher gab es nur Berichte über Angriffsversuche. Jetzt ist die Lücke offiziell als ausgenutzt eingestuft.
Eine Korrektur zu meinem Post auf X und im WhatsApp-Kanal: Dort stand der Patch-Status noch als unklar. Tatsächlich gibt es den Fix schon seit dem 28. Oktober.
Was passiert ist
Die Lücke ist eine sogenannte TOCTOU-Race-Condition. TOCTOU heißt "time of check to time of use": Zwischen dem Moment, in dem ein System etwas prüft, und dem Moment, in dem es das Ergebnis nutzt, bleibt ein kurzes Zeitfenster. Wer in diesem Fenster schneller ist, kann eingreifen.
Bei WordPress betrifft das Core-Updates mit dem vollständigen Update-Paket. Laut WordPress-Advisory GHSA-4w3m-c66w-69mg haben betroffene Versionen die neuen Dateien in ein vorhersagbares Verzeichnis im per Web erreichbaren Upgrade-Ordner entpackt. Wer das Rennen gegen diesen Entpackvorgang gewinnt, kann ohne Anmeldung PHP-Code auf dem Server ausführen. Ein Benutzerkonto oder eine Aktion des Admins braucht es dafür nicht.
Wie ernst ist das?
Bei der Bewertung sind sich die Beteiligten nicht einig. WordPress selbst stuft die Lücke als "Low" ein. Der CVE-Eintrag kommt laut Ostorlab und runZero auf CVSS 8.1, also "High". CVSS ist die übliche Punkteskala für Schweregrade von 0 bis 10. Der Unterschied kommt vom Zeitfenster: Es dauert nur Sekunden, ein Angriff ist also schwierig. In der hohen Wertung steckt das als "hohe Angriffskomplexität" schon drin.
Zum Ablauf: Laut Ostorlab hat Wordfence in den 24 Stunden bis zum 30. Oktober fast 63.000 Anfragen geblockt, die auf die Lücke zielten. Das waren Versuche, keine bestätigten Einbrüche. CISA nennt in der KEV-Meldung keine Details zu erfolgreichen Angriffen, die Aufnahme beruht aber auf "evidence of active exploitation". Wie viele Seiten tatsächlich kompromittiert wurden, ist öffentlich nicht bekannt.
Meine Einschätzung: "Schwer auszunutzen" reicht nicht als Ausrede. Die Angriffe laufen automatisiert und massenhaft, und WordPress läuft auf unzähligen Servern. Wer oft genug probiert, gewinnt irgendwann ein Rennen.
Wer betroffen ist
Betroffen sind laut Advisory alle WordPress-Versionen von 4.7.0 bis 7.1.3. Behoben ist die Lücke in 7.1.4 sowie in Backports für jeden älteren Zweig bis 4.7, zum Beispiel 7.0.8, 6.9.11, 6.8.12 und 4.7.39. Die vollständige Liste steht im Advisory. Pantheon beschreibt 7.1.4 als Sicherheitsrelease mit insgesamt 13 behobenen Problemen, darunter mehrere Stored-XSS-Lücken.
Wichtig ist eine Bedingung: Ausnutzbar ist die Lücke laut Ostorlab nur, wenn das Staging-Verzeichnis unter wp-content/upgrade/ vom Web aus erreichbar ist und PHP-Dateien darin ausgeführt werden. Bei vielen Standard-Hostings ist das der Fall.
Was du jetzt tun solltest
- Updaten. Mach ein Backup und spiel dann 7.1.4 oder die gepatchte Version deines Zweigs ein. Das Advisory nennt das als Gegenmaßnahme.
- Das Paradox bei Auto-Updates beachten. Automatische Hintergrund-Updates liefern den Fix aus. Das Update selbst läuft aber noch mit dem alten, verwundbaren Code. Wie Ostorlab erklärt, ist genau dieses eine Update-Fenster also noch angreifbar.
- Upgrade-Ordner sperren, wenn du nicht sofort updaten kannst. Blockiere den Web-Zugriff auf
/wp-content/upgrade/am Webserver, etwa mit einer 403-Regel. Das deckt nur diese Lücke ab und ersetzt kein Update. Am besten setzt du die Sperre vor dem Update, dann ist auch das Update-Fenster geschützt. - Logs und Verzeichnis prüfen. Such in den Webserver-Logs nach Aufrufen von PHP-Dateien unter diesem Pfad. Achte im Verzeichnis auf PHP-Dateien, die dort nicht hingehören. Ein einzelner Treffer ist ein Hinweis, dem du nachgehen solltest, aber noch kein Beweis für einen Einbruch.
- Reste aufräumen. Lösch nach dem Update übrig gebliebene Dateien im Upgrade-Ordner.
Wer viele Seiten betreut, also Agenturen und Hoster, sollte die Sperre zentral auf Serverebene setzen. Das geht schneller, als jede Installation einzeln anzufassen.