Kritische Lücke im Update-Mechanismus: Während eines Core-Upgrades von WordPress können nicht angemeldete Angreifer über eine Race Condition PHP-Code ausführen. CISA bestätigt aktive Ausnutzung in freier Wildbahn.

1. Executive Summary

CVE-2026-119977 betrifft WordPress Core: Während eines vollständigen Core-Upgrades kann ein nicht angemeldeter Angreifer unter bestimmten Voraussetzungen PHP-Code auf dem Server ausführen. [1] [2] CISA hat die Schwachstelle am 3. November 2026 aufgrund bestätigter aktiver Ausnutzung in den KEV-Katalog aufgenommen; Security Affairs und The Hacker News berichten heute, am 4. November, darüber. [3] [4] [5]

Der offizielle CNA bewertet sie mit CVSS v3.1: 8,1 – High, wobei das kurze, zu treffende Upgrade-Fenster die Angriffskomplexität erhöht. [2] Betreiber sollten WordPress 7.1.4 oder den passenden Sicherheits-Backport installieren, den Update-Prozess absichern und auf zurückliegende Angriffsindikatoren prüfen. [1] [6] [7]

Kernerkenntnisse der Analyse
  • Core-Lücke beim Upgrade: Betroffen ist der temporäre Staging-Bereich unter wp-content/upgrade während eines Core-Updates.
  • Aktive Ausnutzung bestätigt: Aufnahme in den CISA KEV-Katalog am 3. November 2026; automatisierte Scanner suchen nach gestagten Installer-Dateien.
  • Zielstand 7.1.4 & Backports: Alle Zweige von 4.7 bis 7.1 haben Sicherheits-Releases erhalten; primäre Empfehlung ist WordPress 7.1.4.
  • WAF reicht nicht aus: Da der Zugriff direkt auf PHP-Dateien zielt, greifen WAF-Plugins ohne Server-Level Extended Protection zu spät.

2. Betroffene Systeme & Versionsmatrix

Es handelt sich um eine Core-Schwachstelle, nicht um einen Fehler in einem einzelnen Plugin. Das Herstelleradvisory führt folgende betroffenen Versionsbereiche und die jeweils ersten bereinigten Releases auf; alle Bereichsgrenzen sind einschließlich zu verstehen. [6]

Release-Zweig Verwundbare Stände Erster bereinigter Stand
7.1 (Aktuell) 7.1.0 – 7.1.3 Verwundbar 7.1.4
7.0 7.0.0 – 7.0.7 7.0.8
6.9 6.9.0 – 6.9.10 6.9.11
6.8 6.8.0 – 6.8.11 6.8.12
6.7 6.7.0 – 6.7.10 6.7.11
6.6 6.6.0 – 6.6.10 6.6.11
6.5 – 6.0 6.5.13 / 6.4.13 / 6.3.13 / 6.2.14 / 6.1.15 / 6.0.17 6.5.14 / 6.4.14 / 6.3.14 / 6.2.15 / 6.1.16 / 6.0.18
5.9 – 5.0 5.9.19 bis 5.0.30 5.9.20 bis 5.0.31
4.9 – 4.7 4.9.34 / 4.8.33 / 4.7.38 4.9.35 / 4.8.34 / 4.7.39

Eine pauschale Angabe wie „alle Versionen zwischen 4.7 und 7.1.3“ wäre falsch: Bereits gepatchte ältere Zweige liegen numerisch ebenfalls in dieser Spanne. Die Backports schließen diese konkrete Lücke, ersetzen aber keinen vollständigen Support einer alten Linie. WordPress weist darauf hin, dass nur die jeweils neueste Version aktiv unterstützt wird. Vor 4.7 liegende Installationen sind wegen ihrer Nichterwähnung weder als sicher noch als unterstützt einzustufen. [1] [6]

3. Technischer Angriffsvektor

Die Ursache ist eine TOCTOU Race Condition, also ein zeitlicher Fehler zwischen Prüfung und Verwendung eines Zustands. Betroffene Versionen entpacken ein vollständiges Core-Update in einen vorhersehbaren temporären Baum unter wp-content/upgrade. Dieser kann Installer-Dateien enthalten, die auf entsprechend konfigurierten Webservern direkt erreichbar und als PHP ausführbar sind. [2] [7]

Der Angreifer muss die gestagte WordPress-Kopie während des Upgrade-Fensters erreichen und die erforderlichen Schritte vor deren Bereinigung abschließen. Notwendig sind ein tatsächliches vollständiges Paket-Upgrade, Zugriff auf den temporären Pfad und PHP-Ausführung dort. Es ist keine jederzeit auslösbare RCE gegen jede beliebige WordPress-Anfrage. Wordfence beobachtete im Labor typischerweise ein Fenster von wenigen Sekunden; wiederholte automatisierte Anfragen können die Chance erhöhen, es zu treffen. [7]

Vereinfachter WordPress-Angriffspfad: Ein vollständiges Core-Upgrade erzeugt eine temporäre Installer-Kopie. Bei Webzugriff, PHP-Ausführung und gewonnenem Race-Fenster ist Codeausführung möglich; Patch und Integritätsprüfung sind erforderlich.
Eigene Ablaufgrafik nach Hersteller- und Sicherheitsanbieterangaben, ohne ausführbare Exploit-Sequenz.

Der offizielle Wordfence-CNA-Vektor lautet CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H: Netzwerkangriff, hohe Komplexität, keine benötigten Privilegien und keine Nutzerinteraktion. Der Score 8,1 ist ausdrücklich die CNA-Bewertung aus dem CVE-Record, keine hier berechnete Metrik. [2]

Der Fix randomisiert laut Wordfence den Staging-Pfad, ergänzt einen Index-Schutz und verhindert die unsichere Übernahme gestagter Konfigurationsdaten. Diese Änderungen adressieren den Upgrade-Prozess selbst. [7]

4. Status der Ausnutzung & Bedrohungslage

Aktiv in freier Wildbahn ausgenutzt: Ja. CISA bestätigt dies ausdrücklich. Die Aufnahme erfolgte am 3. November – nicht heute. Auch der Patch ist älter: WordPress veröffentlichte 7.1.4 bereits am 28. Oktober. Heutiger Anlass ist die Fachberichterstattung zur inzwischen behördlich bestätigten Ausnutzung. [1] [3] [4] [5]

Wordfence dokumentiert zahlreiche Anfragen auf gestagte Installer-Pfade. Solche Request-Zähler belegen Angriffsversuche, nicht dieselbe Zahl erfolgreicher Übernahmen. Für eine belastbare Betroffenheitsbewertung müssen Zugriffe, Update-Zeitpunkte und Systemartefakte gemeinsam untersucht werden. [7]

Ransomware-Bezug: Der KEV-Eintrag nennt „Unknown“. Eine Ransomware-Kampagne wird deshalb nicht behauptet. Die Verfügbarkeit eines öffentlich lauffähigen PoC ist in den verwendeten Quellen nicht separat verifiziert; aktive Ausnutzung wird hier aus der Behördenbestätigung abgeleitet, nicht aus einer PoC-Annahme. [8]

CISA nennt den 6. November 2026 als Frist und markiert forensische Triage als erforderlich. Diese behördliche Frist gilt für die erfassten US-Bundesbehörden, nicht als allgemeine gesetzliche Patchfrist für deutsche Unternehmen. [8]

5. Konkrete Sofortmaßnahmen & Patch-Anleitung

  1. Den tatsächlich installierten Stand prüfen:
    Kontrollieren Sie im Dashboard unter Aktualisierungen die installierte Version und den angebotenen Sicherheitsrelease. Automatische Hintergrundupdates können bereits erfolgt sein; verlassen Sie sich nicht allein auf diese Erwartung. [1] [7]
    Bei vorhandener, vertrauenswürdiger WP-CLI können Sie im Installationsverzeichnis als zuständiger Site-Benutzer den Stand auslesen: 
    wp core version --extra
    Der offiziell dokumentierte Befehl zeigt unter anderem Version und Paketsprache. Er nimmt kein Core-Update vor. [9]
  2. Update-Prozess schützen und sofort patchen:
    Erstellen Sie ein nutzbares Backup und koordinieren Sie das Update mit dem Hoster oder Webserver-Verantwortlichen. Da die Lücke gerade im Upgrade-Fenster liegt, gehört der Zugriff auf temporäre PHP-Dateien in diese Abstimmung. Ein bereits vorhandener Schutz darf nicht ungeprüft für ausreichend gehalten werden.
    Installieren Sie anschließend über die offizielle WordPress-Aktualisierung 7.1.4 beziehungsweise den passenden Backport aus der Matrix. Ein kurzfristiger Backport kann die konkrete Lücke schließen; die Migration einer Altinstallation auf eine aktiv unterstützte Version bleibt ein eigener Arbeitsauftrag. [1] [6]
  3. WAF-Konfiguration prüfen (Extended Protection erforderlich):
    Wenn Wordfence eingesetzt wird, prüfen Sie zusätzlich Extended Protection. Der Angriff kann PHP-Dateien direkt aufrufen, ohne zuerst WordPress zu laden. Eine nur innerhalb von WordPress aktive Firewall ist deshalb nicht gleichwertig. Die Regel wird für Wordfence Free laut Anbieter erst am 27. November 2026 bereitgestellt: Warten Sie nicht darauf, und behandeln Sie keine WAF als Ersatz für den Core-Patch. [7]
  4. Upgrade-Zugriffe und Veränderungen untersuchen:
    Sichten Sie bei bislang ungepatchten Installationen die Zugriffe auf PHP-Dateien unter wp-content/upgrade. Korrelieren Sie sie mit Update-Zeitpunkten. Ein einfacher eigener Suchfilter auf einer exportierten lokalen Access-Logkopie lautet: 
    grep -nF '/wp-content/upgrade/' ./access.log.export
    Prüfen Sie außerdem unbekannte Administratoren, unerwartete Plugins und neu hinzugekommene PHP-Dateien. [7]
  5. Core-Integrität prüfen – Grenzen beachten:
    Nach dem Patch kann die offiziell dokumentierte Prüfsummenprüfung einen weiteren Anhaltspunkt liefern: 
    wp core verify-checksums --include-root
    Sie vergleicht Core-Dateien mit WordPress.org-Prüfsummen, ohne WordPress selbst zu laden. Ein erfolgreicher Core-Check ist keine vollständige forensische Entwarnung für Plugins, Uploads, Datenbankinhalte oder bereits entwendete Zugangsdaten. Bei Auffälligkeiten sichern Sie Beweise und leiten Sie eine geordnete Wiederherstellung ein. [10]

6. Fazit & strategische Einordnung

Ein kurzer Angriffszeitraum ist kein verlässlicher Schutz, wenn Angreifer automatisiert auf genau diesen Moment warten. Die zentrale Betriebsfrage lautet deshalb nicht nur „Welche Version läuft?“, sondern auch „Wie war der Upgrade-Prozess erreichbar, und was ist während früherer Updates passiert?“

Die unmittelbare Priorität ist der korrekte Core-Patch auf WordPress 7.1.4 oder die jeweilige Backport-Zielversion. Dazu kommen nachvollziehbare Update-Abläufe, Schutz temporärer Verzeichnisse und eine lückenlose Protokollierung.

7. Offizielle Quellen & Referenzen