CVE-2026-119977: WordPress Core Update-Race-RCE ausgenutzt, im CISA KEV

Diese Woche in unserer Serie InSEKurity of the Week: das Content-Management-System hinter rund vier von zehn Websites im Internet. Am 28. Oktober 2026 hat WordPress das Sicherheits-Release 7.1.4 mit 22 Fixes veröffentlicht. Der schwerwiegendste davon ist CVE-2026-119977, eine Time-of-Check-to-Time-of-Use-Race-Condition (TOCTOU) im Core-Updater, mit der ein nicht authentifizierter Angreifer Code auf dem Server ausführen kann — nicht wegen eines Plugins, nicht wegen eines schwachen Passworts, sondern weil sich die Seite selbst aktualisiert hat. Am 3. November hat CISA die Schwachstelle in den Katalog der Known Exploited Vulnerabilities aufgenommen.

Der Mechanismus ist beinahe elegant. Bei einem Core-Update mit vollständigem Paket entpackt WordPress das neue Release in einen Ordner unterhalb von wp-content/upgrade/, dessen Namen ein Angreifer vorhersagen kann. Dieser Ordner wird in der Regel vom Webserver ausgeliefert, und das entpackte Release enthält WordPress’ eigenen Installer, setup-config.php. Für einige Sekunden ist eine zweite, unkonfigurierte WordPress-Kopie per HTTP erreichbar. Ein Angreifer, der sie in diesem Zeitfenster trifft, kann eine wp-config.php hinterlegen, die auf seine eigene Datenbank zeigt — und der Updater kopiert diese Datei anschließend über die live Konfiguration.

Zwei Dinge machen den Eintrag dieser Woche zu mehr als einer Kuriosität. Erstens die Ironie: Genau das Update, das den Fix ausliefert, läuft noch im alten, verwundbaren Code — die sichere Reihenfolge lautet deshalb erst sperren, dann aktualisieren. Zweitens das Ausmaß: Wordfence zählte innerhalb von 21 Stunden nach der Veröffentlichung mehr als 18.500 bösartige Requests auf gestagte Installer-Pfade. Das WordPress-Projekt selbst stuft das Problem als Low ein; CISA, Wordfence und die Angreifer sehen das offensichtlich anders.

🚨 Zusammenfassung

CVE-ID: CVE-2026-119977 — “WordPress Core 4.7.0 - 7.1.3 - Unauthenticated Upgrade Window Staged Installer Remote Code Execution” (Wordfence)
CVSS-3.1-Score: 8.1 High (Wordfence als CNA), Vektor CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. Das eigene Advisory des WordPress-Projekts bewertet sie mit Low
CWE: CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
Hersteller-Advisory: WordPress 7.1.4 Security Release (28.10.2026) und GHSA-4w3m-c66w-69mg (29.10.2026)
Betroffene Software: WordPress Core 4.7.0 bis 7.1.3 — jeder Branch von 4.7 bis 7.1 vor seinem Sicherheits-Backport. Die verwundbare Updater-Logik reicht bis WordPress 2.7 zurück; die Versionen 2.7 bis 4.6 erhalten keinen Fix
Angriffsvektor: Netzwerk — ein HTTP-Request auf den gestagten Installer setup-config.php unterhalb von wp-content/upgrade/, während ein Core-Update läuft
Authentifizierung erforderlich: Keine
Voraussetzungen: Ein Core-Update mit vollständigem Paket muss laufen (manuell, automatisch oder per WP-CLI), wp-content/upgrade/ muss per HTTP mit PHP-Ausführung erreichbar sein, und der Angreifer muss ein Zeitfenster treffen, das in Labortests nur Sekunden dauerte
Auswirkung: Austausch der live wp-config.php, Übernahme der Seite über eine Neuinstallation und PHP-Codeausführung mit den Rechten des Webservers
Patch-Status: Verfügbar — 7.1.4 und Backports für alle Branches bis hinunter zu 4.7.39
Ausnutzungsstatus: Aktiv ausgenutzt laut CISA; Wordfence meldet massenhafte Scans seit dem Tag nach dem Release
CISA KEV: Gelistet seit 03.11.2026; Frist für US-Bundesbehörden 06.11.2026; Nutzung durch Ransomware: unbekannt

🖥️ Was ist WordPress?

WordPress ist das weltweit meistgenutzte Content-Management-System. Laut W3Techs-Zahlen läuft es auf rund 40 Prozent aller Websites — von privaten Blogs und KMU-Homepages über Nachrichtenportale und Online-Shops auf WooCommerce-Basis bis zu den Marketing-Seiten großer Konzerne. Es ist Open Source, in PHP geschrieben, nutzt MySQL/MariaDB als Datenbank und wird durch Zehntausende Plugins und Themes erweitert.

Was WordPress von den meisten Unternehmensanwendungen unterscheidet, ist die Art, wie es sich aktualisiert: Seit Version 3.7 werden Minor- und Sicherheits-Releases standardmäßig automatisch im Hintergrund installiert. Normalerweise ist das eine der besten Sicherheitsfunktionen des Ökosystems. Bei CVE-2026-119977 bedeutet es, dass der verwundbare Moment von selbst kommt — unbeaufsichtigt, auf Tausenden Seiten gleichzeitig, oft mitten in der Nacht.

Typische Einsatzszenarien

Unternehmens-Websites und Landingpages — häufig von Marketing-Teams oder Agenturen betreut statt von der IT
E-Commerce mit WooCommerce, einschließlich Kundenkonten und Bestelldaten
Intranets, Wissensdatenbanken und Blogs für interne und externe Kommunikation
Shared Hosting und Managed-WordPress-Plattformen — Tausende Seiten pro Server
Headless-CMS-Setups, bei denen WordPress Inhalte über seine REST-API an separate Frontends liefert

Warum WordPress immer wieder im KEV landet

CVE-2026-119977 ist die vierte WordPress-Core-Schwachstelle, die seit Juli 2026 in den CISA-KEV-Katalog aufgenommen wurde — nach CVE-2026-60137 und CVE-2026-63030 (die “wp2shell”-Kette, 21. Juli) sowie CVE-2026-87902 (25. September). Vor Juli waren die einzigen WordPress-Einträge im KEV drei Plugin-Lücken aus dem Jahr 2021. Der Core ist nicht mehr automatisch der sichere Teil einer WordPress-Installation.

🔍 Technische Analyse

Beschreibung der Schwachstelle

Ein WordPress-Core-Update läuft in fünf Schritten ab: Release-Paket herunterladen, unterhalb von wp-content/upgrade/ entpacken, die bekannten Core-Dateien prüfen, das neue Release über die live Seite kopieren und den temporären Ordner löschen. Die Schwachstelle liegt zwischen Schritt 2 (Entpacken) und Schritt 4 (Kopieren).

In diesem Zeitfenster enthält der Staging-Ordner ein vollständiges, unkonfiguriertes WordPress — einschließlich des Installers wordpress/wp-admin/setup-config.php. Liegt wp-content unterhalb des Web-Roots und wird PHP dort ausgeführt (der Standard bei den meisten Hostern), lässt sich dieser Installer per HTTP aufrufen. Umut Bayram, Forscher bei Picus Security und Melder der Lücke, hat gezeigt, dass ein Angreifer damit eine neue wp-config.php in den Staging-Baum schreiben kann. Der Updater kopiert diese Datei anschließend über die live Konfiguration.

Ursachenanalyse

Picus identifiziert drei Schwächen, die erst gemeinsam ausnutzbar werden:

Vorhersagbarer Staging-Pfad. WP_Upgrader::unpack_package() in wp-admin/includes/class-wp-upgrader.php entpackt das Paket mit unzip_file() nach wp-content/upgrade/<package-name>/. In WordPress 5.9.0 bis 7.1.3 wird der Ordnername wieder aus dem Dateinamen des Pakets abgeleitet (über den Content-Disposition-Header). Die Versionen 4.4.0 bis 5.8.x hängen ein sechsstelliges Zufallssuffix an und sind nur ausnutzbar, wenn der Pfad auf anderem Weg bekannt wird; die Versionen 2.7 bis 4.3 verwenden ebenfalls feste oder aus dem Dateinamen abgeleitete Namen.
Ein Installer, der nicht nach oben schaut. setup-config.php prüft nur wordpress/wp-config.php und <package-name>/wp-config.php auf eine bestehende Konfiguration. Es sucht nicht bis zur live wp-config.php im Wurzelverzeichnis der Seite — aus Sicht des Staging-Ordners wirkt die Seite also “noch nicht konfiguriert”.
wp-config.php stand nicht auf der Skip-Liste. update_core() in wp-admin/includes/update-core.php baut eine Skip-Liste (wp-content, wp-includes/version.php) und gleicht Dateien mit get_core_checksums() ab. wp-config.php steht weder im Manifest noch auf der Skip-Liste, also wird eine gestagte Kopie an copy_dir() übergeben und überschreibt die live Datei.

Unerwartete Dateien im Staging-Baum werden nicht abgelehnt — der Prüfschritt kontrolliert nur die Dateien, die WordPress erwartet.

Angriffsvektor

Der Angriff setzt ein passendes Paket voraus: Die Pakete full, no_content und new_bundled enthalten die Installer-Dateien. Partial- und Rollback-Pakete kommen nur infrage, wenn sie setup-config.php, wp-config-sample.php, wp-settings.php und zugehörige Dateien mitliefern.

# NUR ZUR VERANSCHAULICHUNG -- Angriffsablauf nach Picus Security; KEIN funktionsfähiger Exploit.
# Dieser Artikel verweist auf keinen öffentlichen, einsatzfähigen Exploit.

  Opfer-Seite (Core-Update läuft)              Angreifer
  -------------------------------              ---------
  1. lädt wordpress-<ver>.zip herunter
  2. entpackt -> wp-content/upgrade/<package-name>/wordpress/...
                    |
                    |  <-- 3. fragt den vorhersagbaren Pfad ab:
                    |        /wp-content/upgrade/<package-name>/wordpress/wp-admin/setup-config.php
                    |  <-- 4. übermittelt DB-Daten einer leeren Datenbank unter seiner Kontrolle
                    v        -> gestagte wordpress/wp-config.php wird geschrieben
  5. prüft bekannte Core-Dateien (zusätzliche Dateien werden nicht abgelehnt)
  6. copy_dir() -> gestagte wp-config.php überschreibt die live wp-config.php
  7. löscht den Staging-Ordner
                    |
                    v
  Seite verbindet sich jetzt mit der leeren DB des Angreifers und zeigt den Installer
                    |  <-- 8. Angreifer schließt die Installation ab, wird erster Administrator
                    |  <-- 9. lädt ein Plugin hoch -> PHP-Codeausführung als Webserver-Benutzer

Was Verteidiger in ihren Logs sehen werden, ist das Abfragen in Schritt 3: Requests auf PHP-Dateien unter /wp-content/upgrade/. Weil der Request direkt auf eine gestagte PHP-Datei geht, sieht eine Firewall innerhalb von WordPress ihn nie — nur eine Kontrolle am Edge oder auf Webserver-Ebene kann ihn blockieren.

Der Fix — und die Lücke beim ersten Update

WordPress 7.1.4 ändert drei Dinge:

Der Staging-Ordner erhält ein 16-stelliges Zufallssuffix und lässt sich nicht mehr erraten.
wp-content/upgrade/index.php bleibt erhalten (und wird bei Bedarf neu angelegt), damit kein Directory Listing den Pfad verrät.
wp-config.php wird in update_core() auf die Skip-Liste gesetzt.

Der Haken: Das Entpacken läuft im bereits installierten Code. Ein Update von einer ungepatchten Version auf 7.1.4 verwendet also noch den vorhersagbaren Pfad. Die neue update-core.php verhindert zwar, dass die Konfiguration überschrieben wird, aber Picus weist darauf hin, dass der gestagte Installer während genau dieses Updates weiterhin erreichbar ist. Deshalb lautet die empfohlene Reihenfolge: zuerst den Webzugriff auf wp-content/upgrade/ sperren, dann aktualisieren. Das gilt auch für wp core update in WP-CLI, das denselben Codepfad nutzt.

Ausnutzung in freier Wildbahn

29.10.2026 — Einen Tag nach dem Release veröffentlicht Wordfence seine Warnung und beginnt, Requests auf gestagte Installer-Pfade zu blockieren; innerhalb der ersten 21 Stunden folgen mehr als 18.500 bösartige Requests. Wordfence beobachtete, wie Angreifer zahlreiche Varianten des Pfads durchprobierten.
31.10. / 01.11.2026 — In einem Update am Wochenende meldet Wordfence, in den vergangenen 24 Stunden 13.095 Angriffe auf diese Schwachstelle blockiert zu haben (BleepingComputer).
03.11.2026 — CISA nimmt CVE-2026-119977 mit einer dreitägigen Frist für Bundesbehörden in den KEV auf. CISA nennt keine Details zu beobachteten Kompromittierungen.

Die Wordfence-Zahlen zählen Requests, keine erfolgreichen Kompromittierungen — ein einzelner Angreifer muss genau den Moment treffen, in dem sich eine bestimmte Seite aktualisiert. Präzision brauchen Angreifer aber nicht, wenn sie einfach Tausende Seiten ununterbrochen abfragen und den Hintergrund-Updater das Fenster für sie öffnen lassen.

Auswirkungen nach erfolgreicher Ausnutzung

Übernahme der Seite — der Angreifer wird erster Administrator einer WordPress-Instanz, die auf dem Server des Opfers läuft.
PHP-Codeausführung mit den Rechten des Webservers über den Upload eines Plugins oder Themes — Webshells und dauerhafte Backdoors folgen.
Verlust der ursprünglichen Konfiguration — die live wp-config.php samt Datenbank-Zugangsdaten und Salts wird überschrieben; die Seite bricht zusammen oder zeigt den Installationsbildschirm.
Zugriff auf das Dateisystem — wp-content/uploads, Backups, andere Webanwendungen und bei Shared Hosting unter Umständen benachbarte Seiten desselben Benutzers.
Missbrauch der Domain — SEO-Spam, Malware-Verteilung, Phishing-Seiten und Weiterleitungen unter einem vertrauenswürdigen Namen.
Pivoting vom Webserver in interne Netze, wenn der Server mehr Reichweite hat, als er haben sollte.

📊 Folgenabschätzung

Unmittelbare Auswirkungen

RCE ohne Authentifizierung auf jeder WordPress-Seite, deren Upgrade-Ordner per Web erreichbar ist, bei jedem Core-Update mit vollständigem Paket
Das Zeitfenster öffnet sich bei jedem Update erneut — auch bei unbeaufsichtigten Hintergrund-Updates
Massenhafte Scans laufen bereits, und der Request braucht weder Zugangsdaten noch Benutzerinteraktion noch ein Plugin

Betroffene Versionen

Branch	Verwundbar	Behoben in
7.1	7.1.0 - 7.1.3	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.5.0 - 6.5.13	6.5.14
6.4	6.4.0 - 6.4.13	6.4.14
6.3	6.3.0 - 6.3.13	6.3.14
6.2	6.2.0 - 6.2.14	6.2.15
6.1	6.1.0 - 6.1.15	6.1.16
6.0	6.0.0 - 6.0.17	6.0.18
5.9	5.9.0 - 5.9.19	5.9.20
5.8	5.8.0 - 5.8.18	5.8.19
5.7	5.7.0 - 5.7.20	5.7.21
5.6	5.6.0 - 5.6.22	5.6.23
5.5	5.5.0 - 5.5.23	5.5.24
5.4	5.4.0 - 5.4.24	5.4.25
5.3	5.3.0 - 5.3.26	5.3.27
5.2	5.2.0 - 5.2.29	5.2.30
5.1	5.1.0 - 5.1.27	5.1.28
5.0	5.0.0 - 5.0.30	5.0.31
4.9	4.9.0 - 4.9.34	4.9.35
4.8	4.8.0 - 4.8.33	4.8.34
4.7	4.7.0 - 4.7.38	4.7.39
2.7 - 4.6	Updater-Logik betroffen	kein Fix — auf einen unterstützten Branch aktualisieren

Quelle: GHSA-4w3m-c66w-69mg. WordPress unterstützt aktiv nur den neuesten Branch; die Backports sind ein Entgegenkommen.

Betroffene Umgebungen

Shared Hosting und Agentur-Plattformen mit vielen WordPress-Seiten, Standard-Document-Roots und automatischen Updates — das attraktivste Ziel für automatisiertes Abfragen
Selbst gehostetes WordPress auf Apache oder nginx, bei dem wp-content unterhalb des Web-Roots liegt und PHP in jedem Verzeichnis ausgeführt wird
Seiten, deren Webserver ausgehende Datenbankverbindungen aufbauen können — die veröffentlichte Kette setzt voraus, dass der Server eine Datenbank des Angreifers erreicht
Seiten ohne Edge-WAF — WordPress-Sicherheits-Plugins sehen Requests auf die gestagte Datei nicht

Managed-Plattformen, die Core-Updates in der Anwendung deaktivieren, wp-content/upgrade/ ohne PHP-Ausführung ausliefern oder WordPress als unveränderliches Image deployen, sind deutlich weniger exponiert.

Angreiferprofile

Opportunistische Botnetz-Betreiber, die auf vertrauenswürdigen Domains Infrastruktur für SEO-Spam, Malware-Hosting und Phishing aufbauen
Initial Access Broker, die Webshells auf Unternehmens-Webservern sammeln und weiterverkaufen
Ransomware- und Datendiebstahl-Akteure — die wp2shell-Kette wurde in diesem Jahr genutzt, um Daten von kleinen Unternehmen und Behörden zu stehlen

🛡️ Mitigationsstrategien

Sofortmaßnahmen (Priorität 1)

1. Ermitteln Sie, welche WordPress-Versionen Sie betreiben.

# Mit WP-CLI: gibt die installierte Core-Version aus, z. B. "7.1.3"
wp core version --path=/var/www/html

# Ohne WP-CLI: Version direkt aus wp-includes/version.php lesen
grep '^\$wp_version' /var/www/html/wp-includes/version.php

# Hosting-Server: Version jeder WordPress-Installation unterhalb von /var/www auflisten
find /var/www -path '*/wp-includes/version.php' -exec grep -H '^\$wp_version' {} \;

Vergleichen Sie das Ergebnis mit der Spalte “Behoben in” oben.

2. Sperren Sie den Webzugriff auf wp-content/upgrade/ — bevor Sie aktualisieren. Legen Sie keine .htaccess innerhalb von wp-content/upgrade/ an: Der ungepatchte Updater räumt diesen Ordner auf und löscht sie.

# nginx: im server { }-Block jeder WordPress-Seite.
# Der Modifier ^~ verhindert, dass Regex-Locations (etwa das übliche "location ~ \.php$")
# vorher greifen -- PHP-Dateien unterhalb dieses Pfads werden so nie ausgeführt.
location ^~ /wp-content/upgrade/ {
    deny all;
}

# Apache 2.4: in der Virtual-Host-Konfiguration (Pfad an Ihr Document Root anpassen)
<Directory "/var/www/html/wp-content/upgrade">
    Require all denied
</Directory>

# Apache, wenn Sie nur die .htaccess im WordPress-Wurzelverzeichnis bearbeiten können
# (erfordert AllowOverride FileInfo). Liefert 403 für alles unterhalb des Pfads.
RedirectMatch 403 ^/wp-content/upgrade/

# Konfigurationssyntax prüfen und Webserver neu laden
sudo nginx -t && sudo systemctl reload nginx
# Apache unter Debian/Ubuntu (auf RHEL-basierten Systemen "httpd" statt "apache2")
sudo apachectl configtest && sudo systemctl reload apache2

# Prüfen: Ein Request unterhalb des Upgrade-Ordners muss jetzt 403 liefern (vorher: 404 oder 200)
curl -s -o /dev/null -w '%{http_code}\n' https://www.example.com/wp-content/upgrade/probe.php

3. Aktualisieren Sie den WordPress-Core.

# WP-CLI: auf das neueste Release aktualisieren (zum Zeitpunkt des Schreibens 7.1.4).
# Erst NACH Schritt 2 ausführen -- das Update selbst läuft noch im alten, verwundbaren Code.
wp core update --path=/var/www/html

# Sie bleiben auf einem älteren Branch? --minor installiert nur das neueste Minor-Release
# des aktuellen Branches (z. B. 6.9.10 -> 6.9.11)
wp core update --minor --path=/var/www/html

# Datenbankänderungen anwenden und neue Version bestätigen
wp core update-db --path=/var/www/html
wp core version --path=/var/www/html

Wenn Sie den Updater gar nicht erst laufen lassen möchten, aktualisieren Sie manuell wie in der WordPress-Dokumentation beschrieben: Release außerhalb des Web-Roots entpacken und die Core-Dateien ersetzen, aber niemals wp-config.php oder wp-content.

# Release außerhalb des Web-Roots herunterladen und prüfen
cd /tmp && curl -sSO https://wordpress.org/wordpress-7.1.4.tar.gz
curl -sS https://wordpress.org/wordpress-7.1.4.tar.gz.sha1   # mit der nächsten Zeile vergleichen
sha1sum wordpress-7.1.4.tar.gz
mkdir -p /tmp/wp-update && tar -xzf wordpress-7.1.4.tar.gz -C /tmp/wp-update

# wp-admin und wp-includes vollständig ersetzen (entfernt Dateien, die aus dem Core gestrichen wurden)
rsync -a --delete /tmp/wp-update/wordpress/wp-admin/ /var/www/html/wp-admin/
rsync -a --delete /tmp/wp-update/wordpress/wp-includes/ /var/www/html/wp-includes/

# Dateien im Wurzelverzeichnis kopieren -- niemals wp-config.php, niemals wp-content
rsync -a --exclude 'wp-content/' --exclude 'wp-admin/' --exclude 'wp-includes/' \
      --exclude 'wp-config.php' /tmp/wp-update/wordpress/ /var/www/html/

# Datenbank-Upgrade ausführen
wp core update-db --path=/var/www/html

Führen Sie die rsync-Befehle als der Benutzer aus, dem die Dateien der Seite gehören, oder korrigieren Sie die Besitzrechte anschließend. Lassen Sie die Sperre aus Schritt 2 dauerhaft bestehen — sie kostet nichts.

Erkennungsmaßnahmen

# 1. Requests auf PHP-Dateien unterhalb von wp-content/upgrade/ (nginx; bei Apache unter Debian/Ubuntu
#    /var/log/apache2/access.log*, unter RHEL /var/log/httpd/access_log*). zgrep liest auch rotierte .gz-Logs.
zgrep -hE '/wp-content/upgrade/[^ ]*\.php' /var/log/nginx/access.log*

# 2. Quell-IPs hinter diesen Requests, aktivste zuerst
zgrep -hE '/wp-content/upgrade/[^ ]*\.php' /var/log/nginx/access.log* \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# 3. Requests auf den gestagten Installer, die mit HTTP 200 BEANTWORTET wurden
#    (Combined-Log-Format: Feld 9 ist der Statuscode). Jeden Treffer als wahrscheinliche Kompromittierung behandeln.
zgrep -hE '/wp-content/upgrade/[^ ]*setup-config\.php' /var/log/nginx/access.log* \
  | awk '$9 == 200'

# 4. PHP-Dateien im Upgrade-Ordner -- außerhalb eines laufenden Updates sollte er (fast) leer sein
find /var/www -path '*/wp-content/upgrade/*' -name '*.php' -type f -ls

# 5. Gehört die wp-config.php noch Ihnen? Datenbank-Host/-Name und letzte Änderung der Datei prüfen
wp config get DB_HOST --path=/var/www/html
wp config get DB_NAME --path=/var/www/html
stat -c '%y %n' /var/www/html/wp-config.php

# 6. Administratoren -- auf Konten achten, die niemand angelegt hat, oder auf eine "frische" Installation mit nur einem Admin
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered --path=/var/www/html

# 7. Plugins -- auf Plugins achten, die niemand installiert hat
wp plugin list --path=/var/www/html

# 8. Integrität der Core-Dateien gegen die Prüfsummen von WordPress.org (deckt wp-config.php und wp-content nicht ab)
wp core verify-checksums --path=/var/www/html

# 9. PHP-Dateien in wp-content, die seit dem Release von 7.1.4 geändert wurden
find /var/www/html/wp-content -name '*.php' -newermt '2026-10-28' -ls

Ein sehr sichtbarer Indikator: Hat eine Seite nach einem Core-Update den WordPress-Installationsbildschirm gezeigt oder plötzlich mit leeren Inhalten gearbeitet, sollten Sie von einem Treffer ausgehen.

# Sigma-Regel -- Request auf eine PHP-Datei im Staging-Ordner des WordPress-Upgrades.
# Nur ein Ausgangspunkt: Legitime Updates rufen diese Dateien nicht per HTTP ab,
# vor dem Alerting trotzdem an Ihre Umgebung anpassen.
title: Request to PHP File in WordPress Upgrade Staging Folder (CVE-2026-119977)
status: experimental
description: Detects HTTP requests for PHP files below wp-content/upgrade/, as used to reach the staged installer during a core update.
references:
    - https://www.picussecurity.com/resource/blog/cve-2026-119977-when-updating-wordpress-becomes-the-vulnerability
logsource:
    category: webserver
detection:
    selection:
        cs-uri-stem|contains: '/wp-content/upgrade/'
        cs-uri-stem|endswith: '.php'
    condition: selection
falsepositives:
    - Unknown
level: high

Wenn Sie eine wahrscheinliche Kompromittierung finden: Nehmen Sie die Seite vom Netz, sichern Sie Logs und Dateisystem, stellen Sie wp-config.php und die Datenbank aus einem nachweislich sauberen Backup wieder her, rotieren Sie das Datenbank-Passwort und die Authentifizierungs-Salts und bauen Sie die Seite aus sauberen Quellen neu auf, statt sie im laufenden Zustand zu bereinigen.

Langfristige Sicherheitsverbesserungen

Halten Sie wp-content/upgrade/ dauerhaft vom Web fern und deaktivieren Sie die PHP-Ausführung in wp-content/uploads/ — beschreibbare Ordner sollten niemals Code ausführen.
Setzen Sie eine WAF vor WordPress, nicht nur hinein. Plugin-basierte Firewalls sind blind für Requests, die an WordPress vorbeigehen.
Beschränken Sie ausgehende Verbindungen von Webservern. Ein Webserver, der keine beliebigen Datenbanken im Internet erreicht, unterbricht die veröffentlichte Angriffskette.
Erwägen Sie unveränderliche Deployments — bauen Sie WordPress mit Composer oder als Container-Image, deployen Sie das Ergebnis und deaktivieren Sie In-Place-Core-Updates in Produktion.
Inventarisieren Sie jede WordPress-Seite, auch die von Marketing oder einer Agentur betriebenen. Was Sie nicht kennen, können Sie nicht patchen.
Überwachen Sie die Dateiintegrität von wp-config.php und den Core-Dateien und alarmieren Sie bei neuen Administrator-Konten.
Lösen Sie nicht unterstützte Branches ab: Die Versionen 2.7 bis 4.6 werden nie einen Fix erhalten, und offiziell unterstützt wird nur der neueste Branch.

⚠️ Warum ist das kritisch?

Bestätigte Ausnutzung — Aufnahme in den CISA KEV mit dreitägiger Frist für Bundesbehörden.
Ohne Authentifizierung, ohne Plugin — die Lücke steckt im Core, jede Standardinstallation ist ein Kandidat.
Der Patch-Prozess ist die Angriffsfläche — automatische Updates öffnen das Zeitfenster von selbst, und das Update auf 7.1.4 ist selbst noch exponiert.
Massenhafte Scans innerhalb eines Tages — Zehntausende Requests auf gestagte Installer-Pfade.
Unsichtbar für Schutz innerhalb der Anwendung — WordPress-Sicherheits-Plugins sehen den Request nicht.
Der Hersteller bewertet sie mit Low — eine Einstufung, die Teams dazu verleiten kann, genau die Lücke zurückzustellen, nach der Angreifer suchen.

📅 Zeitleiste und Offenlegung

2008 — Die betroffene Updater-Logik erscheint in WordPress 2.7 (laut Picus).
28.10.2026 — WordPress veröffentlicht 7.1.4 mit 22 Sicherheitsfixes, darunter die von Umut Bayram (Picus Security) gemeldete Upgrade-Race-Condition.
29.10.2026 — WordPress veröffentlicht GHSA-4w3m-c66w-69mg (Einstufung Low) mit Backports bis 4.7.39; Wordfence veröffentlicht seine Warnung. Innerhalb von 21 Stunden folgen mehr als 18.500 bösartige Requests.
31.10. / 01.11.2026 — Wordfence meldet 13.095 blockierte Angriffe in 24 Stunden.
03.11.2026 — CISA nimmt CVE-2026-119977 in den KEV-Katalog auf.
04.11.2026 — BleepingComputer und andere berichten über die KEV-Aufnahme.
06.11.2026 — Frist zur Behebung für zivile US-Bundesbehörden.

📚 Ressourcen und Referenzen

🤝 SEKurity Unterstützt Sie

WordPress ist selten das System, das Sicherheitsteams den Schlaf raubt — es ist “nur die Website”, oft von Marketing oder einer Agentur betrieben. CVE-2026-119977 zeigt, warum diese Sicht gefährlich ist: Das Routinemäßigste, was eine gut gepflegte Seite tut, nämlich ihr eigenes Sicherheitsupdate zu installieren, reichte aus, um sie einem anonymen Angreifer auszuliefern. Und die Domain, die dabei übernommen wird, ist die, der Ihre Kunden am meisten vertrauen.

Die sinnvollen Fragen dieser Woche sind konkret. Wie viele WordPress-Seiten laufen unter Ihrem Namen — einschließlich der Kampagnen-Microsite von vor drei Jahren? Wer aktualisiert sie, und wann? Können Ihre Webserver Verbindungen zu beliebigen Hosts im Internet aufbauen? Würde jemand ein neues Administrator-Konto bemerken — oder eine Seite, die um 3 Uhr nachts kurz einen Installationsbildschirm gezeigt hat?

Wir testen Webanwendungen und die Infrastruktur dahinter aus der Perspektive des Angreifers — unauthentifiziert aus dem Internet, mit einem niedrig privilegierten Konto und von einem Brückenkopf auf dem Webserver aus — und zeigen Ihnen, wie weit eine kompromittierte Website tatsächlich in Ihr Netzwerk reicht. Wenn Ihr Webauftritt noch nie Teil eines Penetrationstests war, ist diese Woche der richtige Zeitpunkt, das zu ändern.

Unsere Leistungen

Penetration Testing: Web-Anwendungen, mobile Apps (Android & iOS), SAP-Systeme, Active Directory
Groß angelegte Angriffe: Perimeter-Tests, IT-Infrastruktur-Tests, Red-Team-Engagements
Security Awareness: Phishing-Kampagnen, Hacking-Demonstrationen

Handeln Sie jetzt — bevor es Angreifer tun.

Kontakt:

Website: www.sekurity.de

Anfragen: www.sekurity.de/contact

LinkedIn: SEKurity GmbH

Ihr SEKurity Team — Your Trusted Adversaries

Die Sicherheit Ihres Webauftritts und der Server dahinter ist unser Antrieb.

Quellen

WordPress — WordPress 7.1.4 Security Release — Release-Datum, 22 Fixes, Beschreibung der RCE im Upgrade-Zeitfenster, Melder, Backports, automatische Updates, Gutenberg 24.3
WordPress — GHSA-4w3m-c66w-69mg — Einstufung “Low”, Beschreibung, Veröffentlichungsdatum, betroffene und gepatchte Versionen für jeden Branch von 4.7 bis 7.1
Picus Security — CVE-2026-119977: When Updating WordPress Becomes the Vulnerability — Root Cause (unpack_package(), setup-config.php, update_core()), Historie des Staging-Pfads, passende Pakete, Details zum Fix, Lücke beim ersten Update, Mitigationen für nginx/Apache/.htaccess, Hinweise zum manuellen Update
Wordfence — WordPress Core 4.7.0 - 7.1.3 Unauthenticated Upgrade Window Staged Installer RCE — CNA-Eintrag, CVSS 8.1, betroffener Versionsbereich
BleepingComputer — CISA flags WordPress RCE flaw as actively exploited in attacks — KEV-Aufnahme, Frist nach BOD 26-04, 13.095 von Wordfence blockierte Angriffe, Hintergrund zu wp2shell
CISA — Known Exploited Vulnerabilities Catalog (CVE-2026-119977) — Bezeichnung der Schwachstelle, Aufnahmedatum, Frist, geforderte Maßnahmen, Ransomware-Status
Webhosting.Today — CISA lists a fourth WordPress core flaw since July; WordPress rates this one low — unterschiedliche Bewertungen, im Labor gemessenes Zeitfenster von Sekunden, toter Winkel von Firewalls, frühere WordPress-Core-Einträge im KEV, Empfehlungen für Hoster
Daily Security Review — WordPress 7.1.4 Fixes Core RCE Flaw Attackers Are Probing — Wordfence-Warnung am 29.10.2026, 18.500 Requests in 21 Stunden
Barn2 — WordPress market share in 2026 — W3Techs-Nutzungsanteil von rund 40 Prozent aller Websites
WP-CLI — wp core update, wp user list, wp config get, wp core verify-checksums — Syntax und Optionen der in diesem Artikel verwendeten Befehle
WordPress Developer Resources — Upgrading WordPress — Schritte für das manuelle Update (wp-config.php und wp-content behalten)
Apache HTTP Server — mod_alias — RedirectMatch mit Statuscodes außerhalb von 3xx und Kontext .htaccess
EntryZero — Top 5 Hacker-relevant Vulnerabilities (wöchentliches Briefing) — wöchentliches Schwachstellen-Briefing, das für die Themenauswahl herangezogen wurde

InSEKurity of the Week (CW45/2026): WordPress Core Upgrade Race Condition RCE (CVE-2026-119977)