WordPress 7.1.4 Sicherheitslücke: Die Race Condition beim Core-Update (CVE-2026-119977)

Stellen Sie sich vor, Ihre WordPress-Website aktualisiert sich – automatisch, wie gewünscht, mitten in der Nacht. Während WordPress die neuen Dateien entpackt, öffnet sich für einige Sekunden ein Verzeichnis im Web, das nicht offen sein sollte. Wer in diesem Moment den richtigen Pfad kennt, kann ohne Anmeldung PHP-Code ausführen. Das ist keine Theorie aus einem Lehrbuch – das ist das Szenario hinter CVE-2026-119977, der schwerwiegendsten Lücke in WordPress 7.1.4.

Am 28. Oktober 2026 hat WordPress das Sicherheitsrelease 7.1.4 veröffentlicht und empfiehlt eine sofortige Aktualisierung. Es schließt laut WordPress-Dokumentation 22 Sicherheitslücken. Die Schwere dieser speziellen Lücke wird je nach Quelle sehr unterschiedlich bewertet. Dieser Artikel erklärt, was dahintersteckt, warum die Einschätzungen auseinandergehen – und was das für Ihre konkrete Entscheidung bedeutet.

Was CVE-2026-119977 ist – und wie der Angriff im Grundprinzip funktioniert

Die Lücke betrifft den Mechanismus, mit dem WordPress sich selbst aktualisiert. Läuft ein Core-Update mit dem vollständigen Installationspaket, entpackt WordPress die neuen Dateien in ein temporäres Verzeichnis unterhalb von wp-content/upgrade. Der Pfad dieses Verzeichnisses ist vorhersagbar. Auf vielen Servern ist wp-content/upgrade aus dem Web direkt erreichbar, und die temporäre Kopie enthält den WordPress-Installer.

Zugang erhält, wer sich in diesem kurzen Moment am richtigen Pfad befindet und PHP-Dateien aus dem Staging-Verzeichnis aufruft. Eine Anmeldung ist dafür nicht erforderlich. Der Code, der dieses Verhalten ermöglicht, geht laut Patchstack auf WordPress 2.8 zurück – er ist also rund 15 Jahre alt.

Gemeldet wurde die Lücke von Umut Bayram.

Die Voraussetzungen für einen erfolgreichen Angriff

Das Angriffsszenario klingt gefährlich – ist aber an mehrere Bedingungen geknüpft, die gleichzeitig erfüllt sein müssen:

• Das Update wird mit dem vollständigen Paket durchgeführt (nicht als Delta-Update)
• Das Verzeichnis wp-content/upgrade ist vom Web aus erreichbar und nicht durch eine serverseitige Konfiguration geschützt
• PHP-Anfragen an dieses Verzeichnis werden vom Webserver ausgeführt
• Der Angreifer findet oder kennt den Pfad des temporären Staging-Verzeichnisses
• Er trifft genau in dem Sekunden-Zeitfenster ein, bevor WordPress aufräumt

In Laborumgebungen hat Wordfence das Zeitfenster auf wenige Sekunden beziffert. Patchstack hält die Lücke deshalb für nicht praktikabel ausnutzbar, weist jedoch darauf hin, dass sich dieses Fenster bei jedem Update erneut öffnet – auch bei unbeaufsichtigten automatischen Updates.

Die uneinheitliche Bewertung: Warum WordPress „Low" und Wordfence „High" sagt

Wer mehrere Quellen liest, stößt auf eine verwirrende Diskrepanz. Wordfence vergibt als CNA (CVE Numbering Authority) für CVE-2026-119977 den CVSS-3.1-Basiswert 8.1 „High" mit dem Angriffsvektor AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. Das bedeutet: Netzwerkangriff, hohe Komplexität, keine Anmeldung nötig, keine Nutzerinteraktion, volles Schadenspotenzial für Vertraulichkeit, Integrität und Verfügbarkeit.

Das GitHub-Advisory von WordPress selbst (GHSA-4w3m-c66w-69mg, veröffentlicht am 29. Oktober 2026) stuft dieselbe Lücke als „Low" ein und nennt keine CVE-Nummer. Der CVE-Eintrag wurde am 31. Oktober 2026 veröffentlicht; in der National Vulnerability Database steht er mit dem Status „Deferred" ohne eigene Bewertung (Stand 3. November 2026).

Wie ist das zu erklären? CVSS-Basiswerte bilden die maximale Schwere einer Lücke ab, wenn alle ungünstigsten Voraussetzungen erfüllt sind. Die hohe Angriffskomplexität (AC:H) drückt den Score bereits erheblich. Die niedrige Einstufung durch WordPress dürfte die Einschätzung widerspiegeln, dass reale Ausnutzung aufgrund der engen Zeitbedingungen unwahrscheinlich ist. Beide Sichtweisen sind sachlich nachvollziehbar – sie beleuchten nur unterschiedliche Aspekte desselben Problems.

Für Betreiber bedeutet das: Die Lücke ist kein Grund zur Panik, aber auch keine Kleinigkeit, die man ignorieren kann.

Was Wordfence an Ausnutzungsversuchen beobachtet hat

Wordfence ist als einzige der vorliegenden Quellen mit konkreten Angriffszahlen an die Öffentlichkeit gegangen. Diese Zahlen sind ausdrücklich als Herstellerangabe aus einer einzelnen Quelle zu verstehen und beziehen sich auf die Sicht der Wordfence-Firewall:

• 28. Oktober 2026, 20:30 UTC: Wordfence rollte eine Firewall-Regel für Premium-, Care- und Response-Kunden aus – etwa drei Stunden nach dem WordPress-Release.
• Neun Minuten nach der Regel: der erste Treffer.
• Innerhalb von 21 Stunden: mehr als 18.500 Anfragen auf Pfade des zwischengespeicherten Installers.
• Zwei der größten Quellen fragten kleine Gruppen von Websites über rund 14,5 Stunden wiederholt ab.

Wordfence spricht von Ausnutzungsversuchen. Bestätigte erfolgreiche Kompromittierungen werden in der Analyse nicht genannt. Nutzer der kostenlosen Wordfence-Version erhalten diese Firewall-Regel erst am 27. November 2026.

Ein wichtiger technischer Hinweis zur Firewall-Schutzwirkung: Weil der Angreifer direkt eine PHP-Datei aufruft, ohne WordPress zu laden, kann eine Firewall auf Plugin-Ebene diese Anfrage nur mit vorgelagertem Schutz abfangen. Bei Wordfence heißt diese Funktion „Extended Protection". Ohne sie schützt die Firewall in diesem speziellen Szenario nicht.

CVE-2026-119977 steht nicht im CISA-Katalog der bekannt ausgenutzten Schwachstellen (KEV-Katalogstand: 30. Oktober 2026, geprüft am 3. November 2026).

Das französische Behörden-CERT CERT-FR hat am 29. Oktober 2026 die Meldung CERTFR-2026-AVI-1420 veröffentlicht und nennt Codeausführung aus der Ferne, Cross-Site-Scripting und Denial of Service als Risiken für Versionen vor 7.1.4.

Betroffene Versionen und die Korrektur

Betroffen sind alle WordPress-Versionen von 4.7 bis 7.1.3. Das ist faktisch jede aktiv gepflegte WordPress-Installation, die nicht auf dem neuesten Stand ist.

WordPress hat gleichzeitig mit Version 7.1.4 Backport-Patches für alle aktiv unterstützten Versionszweige veröffentlicht:

WordPress 4.6 und älter erhalten keine Sicherheitsupdates mehr. Laut WordPress wird aktiv nur die jeweils neueste Version unterstützt; die Backports sind ein Entgegenkommen an Betreiber, die aus technischen Gründen nicht sofort auf die neueste Hauptversion wechseln können.

Was die Korrektur konkret ändert

Die Korrektur in WordPress 7.1.4 adressiert das Problem auf drei Ebenen:

1. Das Staging-Verzeichnis erhält einen zufälligen Namen anstelle eines vorhersagbaren Pfads.
2. Es wird ein Index-Schutz eingefügt, der direkten Webzugriff verhindert.
3. Konfigurationsdaten aus dem Staging-Bereich werden nicht mehr unsicher übernommen.

Die Kombination dieser Maßnahmen schließt das Angriffsfenster, auch wenn ein Angreifer das temporäre Verzeichnis erraten oder suchen würde.

Die übrigen 21 Sicherheitskorrekturen im Überblick

CVE-2026-119977 war die gravierendste Lücke, aber nicht die einzige. WordPress 7.1.4 schließt laut Advisory außerdem:

Stored Cross-Site Scripting (XSS): Mehrere Stellen im Core ermöglichten gespeicherte XSS-Angriffe – in Blockbegrenzern, dem Kategorien-Block, der Kommentar-Paginierung, der Beitragsnavigation, dem Customizer Selective Refresh, Anfragen zur Löschung personenbezogener Daten, präparierten Benutzernamen sowie im Bild- und Playlist-Block. Die meisten dieser Lücken setzen ein angemeldetes Konto mit mindestens Mitarbeiter-Rechten (Contributor), Autor- oder Redakteursrechten voraus.

Interactivity API: Mehrere Lücken, darunter eine Prototype-Pollution-Schwachstelle und eine Möglichkeit zur dauerhaften Denial-of-Service-Bedingung.

Customizer-Informationspreisgabe: Nicht veröffentlichte Customizer-Änderungen waren ohne Anmeldung einsehbar.

Berechtigungsschwäche: Nutzer mit eigenen Rollen und Kommentar-Moderationsrecht konnten Notizen anlegen, für die sie keine Berechtigung haben sollten.

Root-Zertifikate: Die mitgelieferte Zertifikatsbasis wurde aktualisiert, weil eMudhra-Zertifikate widerrufen wurden.

Praxisbeispiel: Was beim automatischen Update wirklich passiert

Ein hypothetisches, aber typisches Szenario für eine mittelständische Unternehmenswebsite auf WordPress: Automatische Hintergrund-Updates sind aktiviert. Nachts um 3 Uhr startet WordPress das Update auf 7.1.4. Der Prozess läuft in der Regel durch, das Verzeichnis wp-content/upgrade ist aber auf dem Shared-Hosting-Server standardmäßig via Web erreichbar – eine Konfiguration, die bei vielen günstigen Hosting-Paketen noch immer vorkommt.

In diesem Fenster von wenigen Sekunden würde ein automatisierter Scanner, der systematisch Tausende WordPress-Installationen auf diesen Pfad abklopft – exakt das, was Wordfence an den ersten 18.500 Anfragen in 21 Stunden beschreibt –, die Anfrage absenden. Ob der Scanner zur richtigen Sekunde trifft, ist eine Frage der Wahrscheinlichkeit. Patchstack bewertet dies als nicht praktikabel. Wordfence sieht in der Wiederholungsfrequenz (14,5 Stunden anhaltende Abfragen auf einzelne Sites) einen gezielteren Versuch.

Das Update selbst ist der einzige zuverlässige Schutz. Wer zusätzlich wp-content/upgrade auf Webserver-Ebene für externe Anfragen sperrt, schließt das Zeitfenster unabhängig vom Patchstand. Das kostet wenige Minuten Konfigurationsarbeit und ist empfehlenswert, auch wenn 7.1.4 bereits eingespielt ist.

Der Zusammenhang mit CVE-2026-87902 aus WordPress 7.1.2

Wer den Herbst 2026 in WordPress-Sicherheitsmeldungen verfolgt, sollte auch die kritische Lücke aus dem September im Blick haben: Am 22. September 2026 hat WordPress die Version 7.1.2 veröffentlicht, die CVE-2026-87902 schließt – einen Pfad-Traversal-Fehler in der Seitenvorlagen-Auflösung mit einem CVSS-v4.0-Wert von 9.2 „Critical". Diese Lücke wurde von der US-Behörde CISA am 25. September 2026 in den KEV-Katalog der bekannt ausgenutzten Schwachstellen aufgenommen, was bedeutet, dass tatsächliche Angriffe stattgefunden haben.

Wer heute auf WordPress 7.1.4 oder dem jeweiligen Backport-Stand vom 28. Oktober 2026 ist, hat auch CVE-2026-87902 geschlossen. Wer zwar auf 7.1.2 oder 7.1.3 aktualisiert hat, aber 7.1.4 noch aussteht, hat immerhin den kritischeren KEV-Eintrag behoben – aber 22 weitere Lücken noch offen.

Weitere Sicherheitsreleases im Herbst 2026 waren 7.1.1 vom 17. September 2026 (11 Korrekturen) und 7.1.3 vom 6. Oktober 2026 (7 Korrekturen). Die nächste Hauptversion WordPress 7.2 ist laut WordPress-Roadmap für den 8. Dezember 2026 geplant – ein Plan, kein fester Termin.

Mehr zu den WordPress-Sicherheitslücken 2026 und was Unternehmen nach 7.1.2 und 7.1.4 prüfen müssen erfahren Sie im dazugehörigen Überblicksartikel dieser Serie.

Was KMU jetzt konkret tun sollten

Die folgenden Maßnahmen sind in dieser Reihenfolge sinnvoll:

1. Version prüfen – nicht auf das automatische Update vertrauen
Rufen Sie im WordPress-Dashboard unter „Aktualisierungen" nach, ob das Update tatsächlich eingespielt wurde. Automatische Hintergrund-Updates können aus verschiedenen Gründen fehlschlagen, ohne dass eine Fehlermeldung erscheint.

2. wp-content/upgrade auf Webserver-Ebene sperren
Unabhängig vom Patchstand ist dieses Verzeichnis kein Inhalt, der aus dem Web erreichbar sein muss. Bei Apache genügt eine .htaccess-Regel; bei Nginx eine location-Direktive. Prüfen Sie zusätzlich, ob Directory Listing deaktiviert ist.

3. Konten mit erhöhten Rechten prüfen
Die XSS-Lücken in 7.1.4 setzen in der Regel Konten mit Mitarbeiter-Rechten oder höher voraus. Prüfen Sie, welche Nutzerkonten diese Rechte haben, und entfernen Sie nicht mehr benötigte Konten.

4. Bei vermutetem Angriff: Spuren suchen
Wenn das Update verzögert eingespielt wurde und Sie sich unsicher sind, suchen Sie nach:

• Unerwarteten Zugriffen auf PHP-Dateien unter wp-content/upgrade in den Zugriffslogs
• Unbekannten Administratorkonten
• Fremden PHP-Dateien im Dateisystem, besonders in Upload-Verzeichnissen
• Unerwarteten oder unbekannten Plugins

5. Wordfence Extended Protection prüfen
Wenn Sie Wordfence nutzen: Die Firewall schützt in diesem Szenario nur mit vorgelagertem Schutz. Prüfen Sie, ob „Extended Protection" aktiviert ist. Die kostenlose Version erhält die Regel für CVE-2026-119977 erst am 27. November 2026 – bis dahin schützt sie nicht.

WordPress-Sicherheit als Dauerthema für KMU

CVE-2026-119977 zeigt ein grundsätzliches Problem: Selbst der Update-Prozess, der Sicherheitslücken schließen soll, kann unter bestimmten Bedingungen selbst zur Angriffsfläche werden. Das ist kein Argument gegen Updates – im Gegenteil, das Update ist der einzige zuverlässige Schutz. Es ist aber ein Argument dafür, WordPress-Installationen nicht als wartungsfreie Infrastruktur zu behandeln.

Für KMU, die WordPress produktiv betreiben – als Unternehmenswebsite, als Shop-Unterbau oder als Content-Plattform – lohnt sich ein Blick auf WordPress-Sicherheit: So schützen Sie Ihre Website zuverlässig. Dort finden Sie die übergreifenden Maßnahmen, die unabhängig von einzelnen CVEs gelten.

Wer grundsätzlich hinterfragt, ob WordPress das richtige System für seinen Anwendungsfall ist, findet im Vergleich Next.js vs. WordPress: Was ist besser für Ihre Unternehmenswebsite? eine strukturierte Entscheidungshilfe. Für sicherheitskritische Anwendungsfälle – etwa Kanzlei- oder Praxiswebsites – ist die Systemwahl eine eigenständige Frage, die über die Installation eines Sicherheitsupdates hinausgeht.

Die Entscheidung für oder gegen WordPress als Plattform ist nicht Gegenstand dieses Artikels. Wer aber bereits WordPress betreibt, kommt an einer regelmäßig gewarteten und geprüften Installation nicht vorbei. Website-Wartung und technische Betreuung für KMU beschreibt, was professioneller laufender Betrieb konkret bedeutet.

Ihre WordPress-Installation prüfen lassen

Ob Ihre WordPress-Website vom Update erfasst wurde, ob wp-content/upgrade aus dem Web erreichbar ist und ob Ihre Server-Konfiguration weitere Risiken enthält, lässt sich in einer gezielten Prüfung klären. SW Business Solutions analysiert WordPress-Installationen für KMU: Versionsstatus, serverseitige Absicherung, Nutzerkontenverwaltung und – auf Wunsch – Logreview auf Zugriffsmuster, die auf frühere Ausnutzungsversuche hindeuten.

Wenn Sie sich unsicher sind, ob Ihre Website betroffen ist oder ob das Update wirklich sauber durchgelaufen ist, sprechen Sie uns an. Eine erste Einschätzung ist unverbindlich und ohne versteckten Aufwand.

Jetzt Betroffenheit prüfen lassen