Ausgerechnet der Moment, in dem eine WordPress-Installation sicherer werden soll, ist derzeit der gefährlichste: Eine Schwachstelle im Kern-Updater erlaubt unauthentifizierten Angreifern, während eines laufenden Updates eigenen Code auf dem Server auszuführen. Die Lücke mit der Kennung CVE-2026-119977 wurde am 28. Oktober mit WordPress 7.1.4 geschlossen. Nur eine Woche später, am 3. November, nahm die US-Behörde CISA sie in ihren Katalog der aktiv ausgenutzten Schwachstellen (KEV) auf.

Entdeckt und gemeldet hat die Lücke Umut Bayram vom Sicherheitsunternehmen Picus Security. Als CVSS-3.1-Wert ist 8.1 gelistet (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H), die Schwäche ist CWE-367 (Time-of-check Time-of-use). CISA setzte Bundesbehörden eine Frist bis zum 6. November, Patches einzuspielen oder betroffene Systeme vom Netz zu nehmen.

Was CVE-2026-119977 technisch anrichtet

WordPress aktualisiert sich selbst, indem es die neue Version in ein temporäres Verzeichnis unterhalb von wp-content/upgrade/ entpackt, dort vorbereitet und erst im zweiten Schritt über die bestehenden Dateien schreibt. Bayram zeigte, dass dieses Staging-Verzeichnis unter bestimmten Umständen vorhersehbare Namen trägt und über das Web erreichbar bleibt. Zwischen „entpackt“ und „überschrieben“ öffnet sich ein kurzes Zeitfenster, in dem ein unauthentifizierter Angreifer Dateien im Staging-Ordner ansprechen und dort liegende Installer-Skripte für sich arbeiten lassen kann.

Das zentrale Werkzeug ist dabei die aus jeder WordPress-Installation bekannte setup-config.php. Im Staging-Verzeichnis läuft sie an, ohne weiter oben im Dateisystem nach einer bereits existierenden wp-config.php zu suchen. Sie geht also von einer frischen Installation aus, akzeptiert vom Angreifer übergebene Datenbank-Zugangsdaten und schreibt eine neue wp-config.php ins Staging-Verzeichnis. Beim nächsten Update-Schritt wird genau diese Datei in den Live-Ordner kopiert – samt beliebigem PHP-Code im Inneren.

Nach Analyse von Picus Security lässt sich der Angriff nicht gegen jede WordPress-Version gleich leicht durchziehen. Zwischen 4.4.0 und 5.8.18 nutzt der Kern zufällige Suffixe für das Staging-Verzeichnis, was die Ausnutzung erschwert, aber nicht unmöglich macht. Ab Version 5.9.0 wurde das Verhalten wieder berechenbarer und damit der Angriff zuverlässiger. Zwar ist der Angriffsvektor nur während eines Updates offen – doch viele WordPress-Installationen laden Updates automatisch nach, und Angreifer müssen lediglich im richtigen Moment zuschlagen.

Symbolbild: Abstrakter blauer Binärcode

Bild: Symbolbild – Binary blue von geralt, Lizenz CC0, via Wikimedia Commons.

CISA bestätigt Angriffe im Feld

Am 3. November 2026 nahm CISA die Lücke in den KEV-Katalog auf. Dort landen nach Vorgabe der Behörde nur Schwachstellen, zu denen sie belastbare Hinweise auf aktive Ausnutzung hat. Technische Details zu den Angriffen nennt die Behörde nicht; sie verweist lediglich darauf, dass dieser Fehlertyp „ein häufiger Angriffsvektor für böswillige Cyber-Akteure“ sei und „erhebliche Risiken für die Bundesverwaltung“ berge. Für US-Bundesbehörden lief die Frist zum Einspielen des Patches am 6. November ab.

Aus Deutschland oder dem deutschsprachigen Raum liegen bislang keine öffentlichen Angriffsmeldungen vor. Angesichts der Verbreitung von WordPress – laut W3Techs-Statistiken läuft auf einem großen Teil aller Websites weltweit WordPress – gelten solche Lücken allerdings innerhalb kurzer Zeit als globales Problem.

Was du jetzt tun solltest

Auf einer verwalteten WordPress-Installation zählt nur eines: Die Version muss mindestens 7.1.4 (vom 28.10.2026) sein. Das Entwickler-Team hat den Patch außerdem bis auf den Branch 4.7 zurückportiert, sodass auch ältere Installationen eine passende Sicherheitsversion bekommen können. Die laufende Version zeigt dir eine beliebige WordPress-Seite im HTML-Quelltext an, aber zuverlässiger ist die Kommandozeile auf dem Server:

grep wp_version wp-includes/version.php
# oder mit WP-CLI
wp core version

Falls Auto-Updates aktiv sind, sollten sie das Problem bereits geschlossen haben – prüfe es trotzdem, denn in Multisite-Installationen oder bei individuellen Deployments schlagen die Auto-Updates manchmal fehl. Nach dem Update lohnt sich ein Blick in wp-content/upgrade/: Liegen dort noch Reste früherer Update-Versuche, kannst du sie gefahrlos entfernen, solange gerade kein Update läuft.

Als zusätzliche Härtung empfiehlt Picus Security, den Webzugriff auf das Update-Verzeichnis grundsätzlich zu sperren. Für Apache in einer .htaccess am Pfad wp-content/upgrade/:

<IfModule mod_authz_core.c>
    Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
    Order deny,allow
    Deny from all
</IfModule>

Für Nginx erledigt das ein Location-Block in der Site-Konfiguration:

location ^~ /wp-content/upgrade/ {
    deny all;
    return 403;
}

Wer WordPress über eigene Pipelines ausrollt, kann die Aktualisierung komplett außerhalb der Webroot bauen und das Ergebnis per Atomic Swap in das Live-Verzeichnis hängen. Dann existiert das anfällige Staging-Verzeichnis im Web gar nicht erst. In jedem Fall gilt: Nach dem Patch sollten Admins in den Logs nach ungewöhnlichen Zugriffen auf wp-content/upgrade/ und neuen Admin-Benutzern suchen. Wer einen solchen Treffer hat, muss die Installation als kompromittiert betrachten – inklusive Rotation aller Datenbank- und API-Zugänge.

Quellen

Bildnachweis