Ein kurzes Zeitfenster während bestimmter WordPress-Core-Upgrades kann Angreifern ermöglichen, Code auf dem Server einer Website auszuführen, ohne sich anzumelden.
Laut dem Canadian Centre for Cyber Security hat CISA CVE-2026-119977 am 3. November in seinen Katalog der bekannten ausgenutzten Schwachstellen aufgenommen, dem Canadian Centre for Cyber Security. Die Schwachstelle betrifft ungepatchte Versionen der WordPress-Zweige von 4.7 bis 7.1.3; ältere Zweige mit dem entsprechenden zurückportierten Patch sind davor geschützt.
Administratoren müssen das Update sicher abschließen und prüfen, ob Angreifer auf ihre Websites zugegriffen haben, bevor der Schutz aktiviert war.
Wie das Upgrade-Zeitfenster WordPress-Websites gefährdet
Die als kritisch eingestufte Schwachstelle mit einem CVSS-Wert von 8,1 betrifft vorhersehbare, über das Web zugängliche Bereitstellungspfade, die während vollständiger Core-Upgrades angelegt werden. Angreifer, die im richtigen Moment auf die temporären Installer-Dateien zugreifen, könnten Code auf dem Server ausführen. Wordfence zufolge dauerte das Zeitfenster in Labortests typischerweise nur wenige Sekunden, doch Angreifer fragten die Pfade wiederholt ab, um den richtigen Moment zu erwischen.
„Auffällig ist, wo diese Schwachstelle steckt: im Upgrade-Prozess. Dadurch öffnet sich das Zeitfenster genau während der Wartungsphase, auf die Teams angewiesen sind, um die Sicherheit zu erhöhen“, sagte Joe Brinkley, Director of Offensive Security Research and Community bei Cobalt.
Die Schwachstelle ist unabhängig von der Bricksforge-Plugin-Schwachstelle, durch die WordPress-Websites für die Ausführung von Code ohne Authentifizierung anfällig wurden. Ein Plugin-Update behebt den Core nicht, und ein Core-Update beseitigt nicht jede anfällige Komponente.
Welche WordPress-Versionen enthalten den Patch?
WordPress veröffentlichte die Version 7.1.4 am 28. Oktober und empfiehlt eine sofortige Aktualisierung. Das Projekt nennt Umut Bayram als Melder der Upgrade-Schwachstelle.
Die Fehlerbehebungen wurden auch in ältere Zweige übernommen. Wordfence führt gepatchte Releases auf wie 7.0.8, 6.9.11, 6.8.12 und 4.7.39. Administratoren sollten die korrigierte Version ihres Zweigs überprüfen, statt davon auszugehen, dass jede Version unter 7.1.4 weiterhin anfällig ist. WordPress zufolge wird nur die jeweils aktuelle Version aktiv unterstützt.
Organisationen sollten diesen Patch priorisieren, da CISA die Schwachstelle als aktiv ausgenutzt eingestuft hat.
Was Administratoren vor dem Abschluss des Vorfalls tun sollten
Ermitteln Sie zunächst jede WordPress-Installation, ihre Core-Version sowie die für Updates zuständige Person oder den zuständigen Anbieter. Vergewissern Sie sich, dass automatische Updates tatsächlich abgeschlossen wurden.
Da die Gefährdung während eines Upgrades auftritt, sollte das Server- oder Hosting-Team den öffentlichen Zugriff auf temporäre Upgrade-Verzeichnisse nach Möglichkeit beschränken. Stimmen Sie diesen Schutz mit dem Update-Prozess ab, ohne die Behebung der Sicherheitslücke zu verzögern.
Beziehen Sie auch Abhängigkeiten ein: Der separate WordPress-Angriff auf die HEIC-Bildverarbeitungzeigt, warum ein CMS-Update allein nicht sicherstellt, dass der Hosting-Stack geschützt ist.
Bayram, Sicherheitsforscher bei Picus Security, sagte, Verteidiger sollten den Schutz testen, sobald sich ihre Gefährdungslage ändert.
„Deshalb kann die Validierung nicht länger bis zum nächsten planmäßigen Test warten. Sie sollte beginnen, sobald sich etwas ändert“, sagte er.
Als Untersuchungsschritt sollten Sie die Zeitstempel kürzlich durchgeführter Upgrades mit den Web-Logs zu Anfragen an bereitgestellte Installer-Dateien unterhalb von wp-content/upgrade abgleichen, insbesondere an setup-config.php. Untersuchen Sie unbekannte Administratorkonten, unerwartete PHP-Dateien, Konfigurationsänderungen und ungewöhnliche ausgehende Verbindungen. Dies sind Ermittlungsansätze; eine verdächtige Anfrage allein beweist keine Kompromittierung.
Wenn Hinweise auf einen Eindringversuch hindeuten, sichern Sie die Logs und ziehen Sie Incident-Response-Experten hinzu, bevor Sie verdächtige Dateien entfernen. Prüfen Sie, ob Angreifer auf Zugangsdaten oder Geheimnisse der Anwendung zugreifen konnten und ob diese ersetzt werden müssen.
Der Unterschied zwischen Patch-Management und Schwachstellenmanagementist hier entscheidend: Ein erfolgreiches Update schließt das anfällige Verhalten, beweist aber nicht, dass der Zugriff eines Angreifers entfernt wurde. Halten Sie vor dem Abschluss der Reaktion den installierten Patch, die Untersuchungsergebnisse und etwaige Lücken in den verfügbaren Beweisen fest. Kunden von Managed-Hosting-Angeboten sollten diese Angaben bei ihrem Anbieter anfordern.
Mehr lesen: Erfahren Sie, was Sicherheitsteams nach den PHP-Patches von Black October überprüfen sollten, darunter frühere Angriffsversuche, Konfigurationsrisiken und die Frage, ob die Patches in allen exponierten Anwendungen aktiv sind.