Blog

UpdraftPlus-Backdoor über UpdraftCentral (keine CVE): Bin ich betroffen?

Zwischen dem 17. und 19. Oktober 2026 haben Angreifer mit gültigen UpdraftCentral-Schlüsseln Backdoor-Plugins auf WordPress-Seiten installiert. Das ist keine Lücke im UpdraftPlus-Code, deshalb gibt es keine CVE. Das Update beendet den Zugriff mit alten Schlüsseln, entfernt aber nichts, was schon installiert wurde. Hier steht, wie du es prüfst und aufräumst.

Veröffentlicht am 26. Oktober 2026 · Stackwatch-Team

Was passiert ist

Am 17. und 18. Oktober 2026 hat TeamUpdraft, der Hersteller von UpdraftPlus, unbefugten Zugriff auf teamupdraft.com festgestellt. Laut Hersteller wurde vermutlich auf die Kundendatenbank zugegriffen, darin auch auf die Verbindungsschlüssel für UpdraftCentral, UpdraftVault und UpdraftClone. Der Einbruch ist bestätigt, woher die missbrauchten Schlüssel genau stammen, ist laut The Hacker News nicht abschließend geklärt.

Danach haben Angreifer mit gültigen UpdraftCentral-Schlüsseln signierte Befehle (plugin.upload_plugin) an verbundene WordPress-Seiten geschickt. WordPress hat darüber ein Backdoor-Plugin installiert und aktiviert. Weil die Befehle korrekt signiert sind, ist das keine Lücke im UpdraftPlus-Code und es gibt keine CVE. Patchstack ordnet es als Schlüsselkompromittierung ein.

Das Backdoor reagiert auf einen geheimen URL-Parameter, legt ein Konto mit der Rolle Editor an und gibt ihm zusätzlich die Rechte manage_options und install_plugins. Der Login läuft per Cookie am Login-Formular vorbei, 2FA und Login-Schutz-Plugins greifen laut Patchstack nicht. Das Konto bleibt bestehen, wenn du das Plugin entfernst.

Betroffene und gefixte Versionen

Komponente	Betroffen	Gefixt ab
UpdraftPlus Free	Seiten mit UpdraftCentral-Cloud-Schlüssel	`1.26.13`
UpdraftPlus Premium	Seiten mit UpdraftCentral-Cloud-Schlüssel	`2.26.13`
UpdraftCentral selbst gehostet	laut TeamUpdraft nicht betroffen	nicht nötig

Die Versionen 1.26.13 und 2.26.13 trennen alle UpdraftCentral-Verbindungen, die vor dem 18. Oktober 2026, 12:07 UTC (13:07 BST), hergestellt wurden. Laut Nethemba löscht 1.26.12 noch keine Schlüssel.
Schlüssel, die danach am 18. Oktober erstellt wurden, bleiben laut Nethemba nach dem Update bestehen. Lösche sie von Hand.
Laut Patchstack können auch Seiten einen Schlüssel haben, die UpdraftCentral nie bewusst genutzt haben (beim Verbinden eines TeamUpdraft-Kontos war ein Häkchen standardmäßig gesetzt). TeamUpdraft bittet Premium-Nutzer, ihre Seiten in jedem Fall zu prüfen.
Wie viele Seiten angegriffen wurden, ist nicht bekannt.

Wird die Lücke ausgenutzt?

Ja. Patchstack sah die erste Backdoor-Installation am 18. Oktober um 15:32 UTC und die jüngste beobachtete am 19. Oktober um 09:23 UTC, dabei 99 verschiedene Plugin-Namen. Nethemba hat den Angriff auf drei eigenen Seiten entdeckt. Künftige Wellen können neue Namen nutzen. Eine CVE gibt es nicht, deshalb steht der Vorfall auch nicht im KEV-Katalog der CISA.

Bin ich betroffen? So prüfst du es

Die Befehle gehen davon aus, dass du WP-CLI im Webroot nutzt und das Tabellenpräfix wp_ heißt.

Gibt es einen UpdraftCentral-Schlüssel?

wp option list --search="updraft_central_localkeys" --fields=option_name

Unbekannte Benutzer, besonders mit der Rolle Editor:

wp user list --role=editor --fields=ID,user_login,user_email,user_registered
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Verdächtig sind Editor-Konten mit Admin-Rechten, E-Mail-Adressen auf @example.org oder @example.com und der Anzeigename „Site Tools“. Bestätigte Beispiele sind data-ops43 und media-staff96. Erkenne die Konten an den Rechten, nicht am Namen.

Neue Plugins seit dem 17. Oktober, auch im Must-Use-Ordner:

find wp-content/plugins wp-content/mu-plugins -maxdepth 1 -newermt 2026-10-17

Die Beschreibung, die laut Patchstack in den Backdoor-Plugins steht:

grep -rl "Small maintenance toolkit: keeps option storage tidy" wp-content/

Eine Datenbank-Option, deren Name auf _sync_token endet:

wp db query "SELECT option_name FROM wp_options WHERE option_name LIKE '%\_sync\_token'"

In den Zugriffslogs deuten Treffer auf den URL-Parameter _9f5696= (laut The Hacker News) oder auf die IP-Adressen 43.250.53.42 und 2a09:bac5:4e21:2e3c::49b:9 auf Aktivität hin. IP-Sperren allein reichen nicht, die Infrastruktur wechselte laut Patchstack innerhalb eines Tages.

Fallstricke

Das Update räumt nicht auf. Es macht alte Schlüssel ungültig, entfernt aber keine installierten Backdoor-Plugins, Konten oder Optionen.

Die Seite im Dashboard zu entfernen reicht nicht. Backups laufen weiter, nur die Fernverwaltung stoppt. Der Schlüssel selbst muss gelöscht werden.

Fehler 500 nicht „reparieren“. Laut Patchstack hat ein Programmierfehler in den bisher analysierten Backdoors zur Folge, dass betroffene Seiten mit HTTP 500 antworten. Wer den Fehler behebt, aktiviert die Backdoor.

Die Plugin-Liste kann täuschen. Laut Nethemba versteckt sich die Variante „Site Health Cache“ per Filter aus der Plugin-Liste und ist trotzdem aktiv. Prüfe deshalb Dateien, nicht nur das Admin-Menü.

Nicht über wp-admin löschen. Laut Patchstack verwischt die Deinstallationsroutine Spuren. Deaktiviere das Plugin und verschiebe es aus dem Webroot.

Das Konto überlebt das Entfernen des Plugins. Lösche Konten und Optionen separat.

Scanner sehen es nicht. Es gibt keine CVE und keine Advisory. Werkzeuge, die auf Advisories und CVE-Einträgen aufbauen, melden dazu nichts, auch Stackwatch nicht. Der Gratis-Check prüft diesen Vorfall deshalb nicht.

Was du jetzt tust

Im WordPress-Dashboard direkt anmelden, nicht über UpdraftCentral.
UpdraftPlus auf 1.26.13 (Free) beziehungsweise 2.26.13 (Premium) oder neuer aktualisieren.
Unter Einstellungen > UpdraftPlus > Erweiterte Werkzeuge > UpdraftCentral alle Verbindungsschlüssel löschen, oder per wp option delete updraft_central_localkeys.
Wie oben prüfen: Benutzer, Plugins (auch Must-Use), Optionen, Logs.
Unbekanntes entfernen, in dieser Reihenfolge: Schlüssel, Plugin (verschieben), Konten und Optionen.
Die Passwörter aller Administratoren ändern und Sitzungen beenden.
Bei bestätigter Kompromittierung ein Backup von vor dem 17. Oktober einspielen und die Dateien mit einer sauberen Installation vergleichen.
Remote-Speicher (Google Drive, Dropbox, S3) neu autorisieren, falls die Seite über UpdraftCentral erreichbar war.
Für das teamupdraft.com-Konto: Passwort ändern, 2FA neu einrichten, das Passwort auch bei anderen Diensten ersetzen. UpdraftVault neu verbinden, bei UpdraftClone neue Keys erzeugen.
Erst danach die Seite wieder mit UpdraftCentral verbinden.

Wenn du nicht sofort patchen kannst

Lösche zuerst die UpdraftCentral-Schlüssel (siehe oben). Das stoppt den Fernzugriff, Backups laufen weiter. Ohne Schlüssel kann ein Angreifer keine Befehle mehr signieren. Prüfe die Seite danach wie beschrieben.

Zur früheren Lücke CVE-2026-10795

Unabhängig von diesem Vorfall wurde am 11. Juni 2026 CVE-2026-10795 (CVSS 8.1) veröffentlicht: eine Authentifizierungsumgehung im UpdraftCentral-Pfad, betroffen sind Versionen bis einschließlich 1.26.4. Laut Patchstack ist sie in 1.26.5 und 2.26.5 gefixt. Mit 1.26.13 und 2.26.13 bist du auch dort abgedeckt.

Quellen

Häufige Fragen

Gibt es eine CVE für den UpdraftCentral-Vorfall?

Nein. Patchstack ordnet ihn als Schlüsselkompromittierung ein, nicht als Fehler im UpdraftPlus-Code. Deshalb gibt es auch keinen KEV-Eintrag und keine Advisory, auf die sich Scanner stützen könnten.

Reicht das Update auf 1.26.13 beziehungsweise 2.26.13?

Nein. Das Update macht alte UpdraftCentral-Schlüssel ungültig, entfernt aber keine bereits installierten Backdoor-Plugins, Konten oder Optionen. Du musst Benutzer, Plugins und Dateien selbst prüfen und den Schlüssel löschen.

Bin ich betroffen, wenn ich UpdraftCentral nie benutzt habe?

Möglicherweise. Laut Patchstack kann auch dann ein Schlüssel existieren, weil beim Verbinden eines TeamUpdraft-Kontos ein Häkchen standardmäßig gesetzt war. Prüfe, ob die Option updraft_central_localkeys vorhanden ist. TeamUpdraft bittet Premium-Nutzer, ihre Seiten in jedem Fall zu prüfen.

Sind meine Backups betroffen?

Laut TeamUpdraft nicht: Backups in deinem eigenen Remote-Speicher sind nicht betroffen. Für eine Wiederherstellung nimmst du ein Backup von vor dem 17. Oktober 2026 und autorisierst den Remote-Speicher danach neu.

Warum zeigt meine Seite Fehler 500?

Laut Patchstack können Backdoors mit einem Programmierfehler dazu führen, dass die Seite mit HTTP 500 antwortet. Behebe den Fehler nicht, das würde die Backdoor aktivieren. Prüfe die Seite wie im Artikel beschrieben.