UpdraftCentral keys nach Übernahmen von WordPress-Websites löschen
UpdraftCentral keys, die aus dem Fernverwaltungsdienst gestohlen wurden, werden zur Installation von backdoors auf verbundenen WordPress-Websites verwendet. Laut Patchstack lief die Kampagne während eines 18-stündigen Zeitfensters am 18. und 19. Oktober 2026 ununterbrochen. Die erste Installation wurde am 18. Oktober um 15:32 Uhr und die jüngste am folgenden Tag um 09:23 Uhr registriert. Im Statusupdate von 08:00 Uhr UTC hieß es, die Ausnutzung sei weiterhin aktiv und es gebe keinen Fix des Anbieters. TeamUpdraft veröffentlichte um 13:00 Uhr UTC einen Beitrag zu dem Sicherheitsvorfall.
Es handelt sich um die Kompromittierung von Credentials und nicht um eine Schwachstelle im UpdraftPlus-Code. Daher stoppt die Installation des neuesten Plugins den Angriff nicht. Alle kostenlosen und kostenpflichtigen UpdraftPlus-Versionen sind betroffen, wenn eine Website über eine aktive UpdraftCentral-Verbindung verfügt, einschließlich der Releases 1.26.11 und 2.26.11. Patchstack bewertete den Vorfall mit einem CVSS-Wert von 9,8 und verwendete dabei die Skala des Common Vulnerability Scoring System für den Schweregrad von Sicherheitsproblemen. UpdraftPlus hat mehr als vier Millionen aktive Installationen, allerdings sind nur Websites, auf denen ein UpdraftCentral key gespeichert ist, dieser Kampagne ausgesetzt.
UpdraftCentral ist ein separater Fernverwaltungsdienst, dessen Client in jeder UpdraftPlus-Installation enthalten ist. Der Client bleibt inaktiv, bis eine Website ein Verbindungs-Credential erhält. Zu diesem Zeitpunkt erstellt die Website ein RSA key pair, also ein zusammengehöriges Paar zur Überprüfung verschlüsselter Anweisungen, und speichert den öffentlichen Teil des Dashboards. Anschließend führt sie Befehle aus, die mit dem entsprechenden privaten Teil signiert wurden, und verwendet dabei die Berechtigungen des WordPress-Benutzers, der die Verbindung eingerichtet hat. Einzelne Befehle erfordern keine weitere Bestätigung.
Eine Website kann ein solches Credential erhalten, indem sie einem UpdraftCentral-Dashboard hinzugefügt oder mit einem TeamUpdraft.com-Konto verbunden wird. Auf der Kontoseite ist die Option, die Website einer zentralen Fernsteuerung hinzuzufügen, standardmäßig ausgewählt. Die Option erscheint nur, wenn noch kein Credential vorhanden ist. Daher kann bereits eine einzige erfolgreiche Kontoverbindung eine Website registrieren, deren Eigentümer UpdraftCentral nicht bewusst verwenden wollte. Laut Patchstack waren im November 2025 ausgegebene Credentials im Oktober 2026 noch gültig, da sie nicht ablaufen. Die privaten Credentials des Dashboards verbleiben im Cloud-Dienst und nicht auf den verbundenen Websites.
Der Angreifer sendet über den Kanal für Fernbefehle eine gültig signierte plugin.upload_plugin-Anweisung. Dieser Kanal akzeptiert gewöhnliche POST requests, also an die Website gesendete Daten. WordPress installiert und aktiviert das bereitgestellte Plugin anschließend über sein normales Installationsprogramm. Nethemba, das die Kampagne auf drei Websites in seiner eigenen Infrastruktur entdeckte und die erste Analyse veröffentlichte, berichtete, dass die lokalen Plugin-Dateien mit offiziellen Releases übereinstimmten, sich die Fingerabdrücke der Credentials über mehrere Tage von Backups hinweg nicht verändert hatten, die Kryptografie korrekt funktionierte und die Logs weder einen unbefugten Administrator noch einen herkömmlichen Plugin-Upload zeigten. Die feindlichen Anfragen kamen aus einer vom Angreifer kontrollierten Infrastruktur und nicht aus den normalen Systemen des Dienstes. Die Belege deuteten daher darauf hin, dass Credentials aus der UpdraftCentral Cloud-Umgebung entwichen waren. TeamUpdraft hatte die Ursache jedoch noch nicht erklärt, als Patchstack seine Ergebnisse veröffentlichte.
Jedes hochgeladene Plugin enthält eine backdoor, die bei jeder WordPress-Anfrage frühzeitig ausgeführt wird und auf einen geheimen URL-Parameter mit einem 32 Zeichen langen Wert wartet. Wird dieser übermittelt, erstellt die backdoor ein Konto mit einem fest eingebauten Passwort und kennzeichnet es als Editor. Anschließend weist sie dem Konto separat manage_options und install_plugins zu, zwei WordPress capabilities, die Änderungen an Einstellungen und die Installation von ausführbarem Plugin-Code erlauben. Der Besucher wird über ein dauerhaftes Browser-Cookie angemeldet und zu wp-admin weitergeleitet, ohne das Anmeldeformular zu durchlaufen. Dadurch werden two-factor authentication, Beschränkungen für Anmeldeversuche und Plugins zum Anmeldeschutz umgangen.
Das getarnte Konto bleibt bestehen, nachdem das schädliche Plugin entfernt wurde, und der Angreifer kennt sein Passwort bereits. Die analysierten Samples enthielten einen Programmierfehler, der einen HTTP 500 server error verursachte, bevor ihre Aktivierungsprüfung ausgeführt werden konnte. Dadurch schlug jede nicht aus dem Cache geladene Seitenanfrage fehl. Dieser sichtbare Ausfall alarmierte die ersten Opfer innerhalb weniger Minuten. Websitebetreiber sollten den schädlichen Code nicht reparieren, da die Behebung des Fehlers sein vorgesehenes Verhalten aktivieren würde.
Patchstack erfasste 99 verschiedene Plugin-Namen. „Site Health Cache“ tauchte wiederholt auf, während die meisten anderen Namen zufällige Kombinationen aus zwei oder drei Wörtern waren, die jeweils nur einmal verwendet wurden. Der zuverlässigere Indikator ist die identische Beschreibung „Small maintenance toolkit: keeps option storage tidy.“ Zu den bestätigten Konten gehörten data-ops43 und media-staff96, es ist jedoch mit weiteren Namen zu rechnen. Weitere Anzeichen sind eine auf @example.org endende Adresse, der Anzeigename „Site Tools“, eine auf _sync_token endende Datenbank-Option, unbekannte WordPress-Fehlermeldungen per E-Mail und Plugin-Installationen ohne entsprechende Administratoraktion.
Die beobachteten Anfragen kamen von 43.250.53.42 und 2a09:bac5:4e21:2e3c::49b:9. Die IPv6-Adresse tauchte ungefähr drei Stunden vor der IPv4-Adresse auf, und beide wurden gleichzeitig verwendet. Da der Angreifer seine Infrastruktur innerhalb eines Tages wechselte, ist das Blockieren dieser Adressen keine ausreichende Schutzmaßnahme. Legitime Fernzugriffe enthalten in ihrer User-Agent-Identifikation eine Bibliotheksversion und eine Dienst-URL; bei den feindlichen Anfragen fehlten beide Angaben. In den UpdraftCentral-Logs kann außerdem probe.central.updraftplus.com gefolgt von „Command received: plugin.upload_plugin.“ erscheinen.
Administratoren sollten auch dann prüfen, ob eine Verbindung besteht, wenn sie UpdraftPlus nur für Backups verwenden. Führen Sie mit WP-CLI, dem Kommandozeilenwerkzeug zur Verwaltung von WordPress, den Befehl wp option get updraft_central_localkeys aus. Jede Ausgabe bedeutet, dass ein Credential vorhanden ist. In wp-admin kann es über Settings, UpdraftPlus Backups, Advanced Tools, UpdraftCentral und anschließend über „Manage existing keys“ entfernt werden, indem jeder Eintrag gelöscht wird. Die WP-CLI-Alternative lautet wp option delete updraft_central_localkeys. Es reicht nicht aus, die Website nur aus dem zentralen Dashboard zu entfernen, da die relevante Kopie auf der Website verbleibt. Geplante Backups werden nach dem Löschen weiterhin ausgeführt; nur die Fernverwaltung wird beendet.
Wenn eine backdoor gefunden wird, entfernen Sie zuerst das UpdraftCentral-Credential, damit der Angreifer keinen Ersatz senden kann. Deaktivieren Sie das Plugin und verschieben Sie es aus dem über das Web erreichbaren Verzeichnis, anstatt es über wp-admin zu löschen, da sein Deinstallationsprozess die eigenen Spuren entfernt. Löschen Sie die zugehörige _sync_token-Option und das verborgene Konto. Wenn dieses Konto existiert oder Zugriffs-Logs den geheimen Aktivierungsparameter zeigen, muss die Website als vollständig kompromittiert behandelt werden: Stellen Sie ein Backup aus der Zeit vor dem Angriff wieder her, vergleichen Sie die Dateien mit einer sauberen WordPress-Installation, überprüfen Sie jeden Benutzer mit zusätzlichen capabilities, ändern Sie die Passwörter der Administratoren und der UpdraftCentral Cloud, beenden Sie alle Sitzungen und aktivieren Sie two-factor authentication. Stellen Sie die Verbindung erst wieder her, wenn die Ursache erklärt wurde. Falls Fernverwaltung unverzichtbar ist, weist Patchstack darauf hin, dass die Verwendung eines Kontos ohne install_plugins den Angriff auf einer öffentlich analysierten Website verhinderte.