CVE-2026-119977 klingt nach Fachchinesisch. Betroffen ist aber jede WordPress-Installation von Version 4.7 bis 7.1.3 – und damit ein großer Teil der Firmenwebsites, die ich zwischen Basel, Lörrach und Freiburg kenne. Die US-Cybersicherheitsbehörde CISA führt die Lücke seit dem 3. November 2026 als aktiv ausgenutzt.
Das Besondere an dieser Lücke: Sie steckt nicht in einem Plugin, sondern im WordPress-Kern selbst – und sie öffnet sich genau in dem Moment, in dem WordPress sich aktualisiert. Auch das Update auf die reparierte Version läuft noch einmal durch dieses Fenster. Wer jetzt einfach auf „Aktualisieren“ klickt, tut grundsätzlich das Richtige, aber nicht in der sichersten Reihenfolge.
Das Wichtigste in Kürze
Was ist CVE-2026-119977?
Bei einer vollständigen Core-Aktualisierung lädt WordPress das neue Paket herunter und entpackt es zunächst in einen Arbeitsordner unter wp-content/upgrade. Erst danach werden die Dateien an ihren endgültigen Platz kopiert und der Arbeitsordner aufgeräumt.
Das Problem: Dieser Ordner liegt bei vielen Servern im öffentlich erreichbaren Bereich, sein Pfad ist vorhersehbar, und die entpackte Kopie enthält auch den WordPress-Installer (setup-config.php). Wer diesen Installer in den wenigen Sekunden zwischen Entpacken und Aufräumen aufruft, kann ihn dazu bringen, eigenen PHP-Code auf dem Server auszuführen. Ein Login ist dafür nicht nötig.
Fachlich ist das eine sogenannte Race Condition: Der Angreifer muss im richtigen Moment „anklopfen“. Das klingt nach Glückssache, ist es aber nicht. Laut Wordfence haben zwei große Angriffsquellen kleine Gruppen von Websites rund 14,5 Stunden lang immer wieder abgefragt – also gezielt auf das Update-Fenster gewartet.
Entdeckt hat die Lücke Umut Bayram von Picus Security. Wordfence hat sie als CVE-Vergabestelle am 31. Oktober 2026 veröffentlicht. Die Sicherheitsversion WordPress 7.1.4 erschien bereits am 28. Oktober und behebt insgesamt 22 Schwachstellen.
Wie ernst ist die Lage?
Ernst genug, um nicht bis zum nächsten Wartungstermin zu warten:
Angriffe begannen sofort. Wordfence registrierte den ersten passenden Angriffsversuch rund neun Minuten nach Veröffentlichung der Sicherheitsmeldung und zählte in den ersten 21 Stunden über 18.500 Anfragen auf die betroffenen Installer-Pfade.
CISA stuft die Lücke als aktiv ausgenutzt ein. US-Bundesbehörden mussten sie bis zum 6. November 2026 schließen. Für Unternehmen in Europa ist das nicht bindend, aber ein klares Signal.
Die kostenlose Wordfence-Firewall schützt noch nicht. Zahlende Kunden bekamen die Firewall-Regel innerhalb von Stunden, die Gratis-Version erst ab dem 27. November 2026.
Zur Einordnung: Die Wordfence-Zahlen messen Angriffsversuche, nicht erfolgreiche Einbrüche. Bestätigte Kompromittierungen durch diese Lücke waren bei Redaktionsschluss nicht öffentlich dokumentiert. Darauf würde ich mich trotzdem nicht verlassen – die meisten Einbrüche bei kleinen Websites fallen erst Wochen später auf.
Das Paradox: Der Fix läuft über den verwundbaren Code
Hier liegt die unangenehme Pointe. Die Lücke öffnet sich während einer Core-Aktualisierung. Die Aktualisierung auf 7.1.4 ist aber selbst eine Core-Aktualisierung – ausgeführt vom alten, noch verwundbaren Updater. Der Fix ist also der letzte riskante Moment.
Das gilt genauso für automatische Hintergrund-Updates. WordPress aktualisiert sich bei Sicherheitsversionen meist selbst, und genau dabei öffnet sich das Fenster ein letztes Mal.
Trotzdem gilt: Nicht aktualisieren ist keine Option. Eine Website, die auf 7.1.3 bleibt, ist bei jedem künftigen Update wieder angreifbar und hat 21 weitere bekannte Lücken offen. Die Lösung ist die richtige Reihenfolge.
Vier Schritte, die ich bei meinen Wartungskunden pro Website durchführe. Dauer: etwa 20 Minuten, wenn Server-Zugriff vorhanden ist.
-
1
Webzugriff auf /wp-content/upgrade/ sperren
Legen Sie auf Webserver-Ebene eine Regel an, die jeden HTTP-Zugriff auf den Ordner
/wp-content/upgrade/mit 403 beantwortet. WordPress selbst greift über das Dateisystem auf den Ordner zu, nicht über HTTP – die Sperre stört das Update also nicht. Beispiele für nginx und Apache finden Sie unten. -
2
Prüfen, dass der Pfad 403 liefert
Rufen Sie von außen eine Adresse unterhalb von
/wp-content/upgrade/auf. Die Antwort muss 403 Forbidden lauten. Kommt 404 oder 200, greift die Regel nicht – etwa weil ein CDN oder ein vorgeschalteter Proxy die Anfrage anders behandelt. -
3
Auf die reparierte Version aktualisieren
Aktualisieren Sie auf WordPress 7.1.4. Wer bewusst auf einem älteren Versionszweig bleibt, braucht dessen Sicherheits-Backport (laut Berichten von 7.0.8 bis hinunter zu 4.7.39). WordPress 4.6 und älter erhalten keine Sicherheitsupdates mehr – hier hilft nur ein vollständiges Upgrade.
-
4
Nach Spuren eines Einbruchs suchen
Prüfen Sie die Liste der Administratoren, vergleichen Sie die Core-Dateien mit den offiziellen Prüfsummen und durchsuchen Sie die Zugriffslogs nach Anfragen auf PHP-Dateien unter
/wp-content/upgrade/rund um vergangene Updates. Die Befehle dafür stehen weiter unten.
nginx – Server-Block
nginx
location ^~ /wp-content/upgrade/ {
deny all;
return 403;
}Apache – VirtualHost
apache
<Directory "/var/www/html/wp-content/upgrade">
Require all denied
</Directory>
# Alternative ohne Server-Zugriff: in der .htaccess im WordPress-Hauptverzeichnis
RedirectMatch 403 ^/wp-content/upgrade/Kontrolle per Kommandozeile
bash
# 1. Greift die Sperre?
curl -sI https://www.ihre-domain.de/wp-content/upgrade/test.php | head -n 1
# 2. Core-Dateien gegen offizielle Prüfsummen prüfen
wp core verify-checksums
# 3. Alle Administratoren auflisten
wp user list --role=administrator
# 4. Zugriffe auf PHP-Dateien im Upgrade-Ordner im Log suchen
zgrep -hE "wp-content/upgrade/.*\.php" /var/log/nginx/access.log* | sort | uniq -c | sort -rn | headWoran Sie einen Einbruch erkennen
Diese Hinweise sollten Sie ernst nehmen:
Administratoren, die niemand angelegt hat – oft mit unauffälligen Namen wie „wpadmin“ oder „support“.
PHP-Dateien, die niemand hochgeladen hat, besonders in
wp-content/upgrade,wp-content/uploadsoder im Hauptverzeichnis.Plugins, die niemand installiert hat, oder Core-Dateien, die bei
wp core verify-checksumsals verändert auffallen.Erfolgreiche Zugriffe (Status 200) auf
/wp-content/upgrade/…/setup-config.phpim Zugriffslog. Ein solcher Treffer während oder kurz nach einem Update sollte als Einbruch behandelt werden.
Bei einem Verdacht gilt: Website vom Netz nehmen oder in den Wartungsmodus versetzen, alle Passwörter und Schlüssel in der wp-config.php erneuern, aus einem sauberen Backup wiederherstellen und erst dann wieder online gehen. Ein bloßes Löschen der verdächtigen Datei reicht selten, weil Angreifer meist mehrere Hintertüren hinterlassen.
„WordPress aktualisiert sich doch automatisch“
Diesen Satz höre ich oft. Seit dieser Lücke ist er keine Sicherheitsstrategie mehr. Drei Gründe:
Automatische Updates können still scheitern. Fehlende Schreibrechte, ein volles Webspace-Kontingent oder ein Plugin-Konflikt – und die Website bleibt unbemerkt auf der alten Version.
Das automatische Update öffnet das Fenster. Ohne vorherige Sperre läuft auch der automatische Fix durch die verwundbare Phase.
Niemand schaut danach. Ob nach dem Update ein fremder Admin im System sitzt, prüft kein automatischer Prozess.
Die entscheidende Frage für jedes Unternehmen ist deshalb nicht „Ist WordPress aktuell?“, sondern: Wer kümmert sich bei uns darum – und wusste diese Person von der Lücke? Bei Shared Hosting lohnt sich eine schriftliche Nachfrage beim Anbieter, ob alle Installationen auf einer reparierten Version laufen und ob der Upgrade-Ordner gesperrt ist.
Wenn Sie unsicher sind, ob Ihre Website betroffen ist, oder die Wartung abgeben möchten: Schreiben Sie mir. Den Check mit Sperre, Update und Kontrolle erledige ich für Firmenwebsites in der Regel am selben Tag.
Welche WordPress-Versionen sind von CVE-2026-119977 betroffen?
Alle Versionen von 4.7.0 bis 7.1.3. Behoben ist die Lücke in WordPress 7.1.4 vom 28. Oktober 2026 sowie in Sicherheits-Backports für ältere Versionszweige. WordPress 4.6 und älter erhält keine Korrektur mehr.
Reicht es, wenn WordPress sich automatisch aktualisiert?
Nicht ganz. Das automatische Update schließt die Lücke, läuft aber selbst noch über den verwundbaren Updater. Sicherer ist es, vorher den Webzugriff auf /wp-content/upgrade/ zu sperren und nach dem Update auf Spuren eines Einbruchs zu prüfen.
Stört die Sperre von /wp-content/upgrade/ künftige Updates?
Nein. WordPress greift beim Update über das Dateisystem auf den Ordner zu, nicht über HTTP. Die Sperre verhindert nur Zugriffe aus dem Internet. Testen Sie nach dem Einrichten trotzdem einmal, ob ein Plugin-Update normal durchläuft.
Schützt mich die kostenlose Version von Wordfence?
Laut Berichten erhält die Gratis-Version die passende Firewall-Regel erst ab dem 27. November 2026. Bis dahin schützt nur die Sperre auf Server-Ebene. Plugin-basierte Firewalls können direkte PHP-Aufrufe zudem verpassen, wenn sie nicht früh genug geladen werden.
Ich habe keinen Server-Zugriff. Was kann ich tun?
Bei Apache-Hosting können Sie die Zeile RedirectMatch 403 ^/wp-content/upgrade/ in die .htaccess im WordPress-Hauptverzeichnis eintragen. Bei Managed Hosting fragen Sie den Anbieter schriftlich, ob alle Installationen gepatcht sind und der Upgrade-Ordner gesperrt ist.
Quellen
The Hacker News (04.11.2026): CISA Confirms Hackers Exploiting WordPress Core Flaw During Software Upgrades — thehackernews.com
The Hacker News (06.11.2026): Installing the Fix for an Exploited WordPress Flaw Can Expose Some Sites One Last Time — thehackernews.com
WordPress.org: WordPress 7.1.4 Security Release (28.10.2026) — wordpress.org
Tech Insider: WordPress CVE-2026-119977, CISA KEV and the 7.1.4 deadline — tech-insider.org
NVD: CVE-2026-119977 — nvd.nist.gov
Stand: 9. November 2026. Zahlen zu Angriffsversuchen stammen von Wordfence und messen Anfragen, nicht bestätigte Einbrüche.
Newsletter abonnieren
Gelegentliche Updates zu Projekten, Design-Themen und neuen Arbeiten. Doppelte Bestätigung. Jederzeit abbestellbar.