UpdraftCentral: Gestohlene Schlüssel öffnen WordPress-Seiten

Was passiert ist

TeamUpdraft stellt das Backup-Plugin UpdraftPlus her und dazu die Fernwartung UpdraftCentral, den Backup-Speicher UpdraftVault und den Kopierdienst UpdraftClone. Am 19. Oktober 2026 veröffentlichte das Unternehmen einen Hinweis zu einem Vorfall und hat ihn seither mehrfach ergänzt, zuletzt am 23. Oktober. Danach gab es am Wochenende des 17. und 18. Oktober einen unbefugten Zugriff auf die Website teamupdraft.com. „We believe our customer database was accessed“, schreibt TeamUpdraft. In dieser Datenbank lagen Namen, E-Mail- und Rechnungsadressen, die Bestellhistorie, die Passwörter der Kundenkonten in gehashter Form, die Einstellungen der Zwei-Faktor-Authentifizierung und die Verbindungsschlüssel für UpdraftCentral, UpdraftVault und UpdraftClone. Kartendaten speichert das Unternehmen nach eigenen Angaben nicht; Zahlungen laufen über Stripe und PayPal.

Nicht betroffen sind nach Angaben von TeamUpdraft das Plugin UpdraftPlus selbst und seine Downloads, selbst gehostete Installationen von UpdraftCentral und Backups, die in eigenem Speicher wie Google Drive, Dropbox oder Amazon S3 liegen. Der Schaden entstand nicht im Code, sondern mit den gestohlenen Schlüsseln.

Die Sicherheitsfirma Patchstack beschrieb am 19. Oktober, was mit ihnen geschah: Ein Angreifer mit gültigen Schlüsseln der UpdraftCentral-Konsole installierte Backdoor-Plugins auf verbundenen WordPress-Seiten. Patchstack zeichnete Installationen vom 18. Oktober, 15:32 Uhr, bis zum 19. Oktober, 09:23 Uhr, auf, rund 18 Stunden lang, unter 99 verschiedenen Plugin-Namen, von denen „Site Health Cache“ immer wieder vorkam. TeamUpdraft bestätigte am 21. Oktober, dass der Angreifer über die Verbindung Administratorkonten angelegt und Schadplugins installiert hat, und schreibt: „the extent of that is unknown“.

Am 19. Oktober erschienen UpdraftPlus 1.26.13 für die freie und 2.26.13 für die Premium-Version. Sie trennen jede UpdraftCentral-Verbindung, die vor dem 18. Oktober, 13:07 Uhr britischer Zeit, hergestellt wurde; die alten Schlüssel gelten danach nicht mehr. Verbindungen, die nach diesem Zeitpunkt neu aufgebaut wurden, bleiben bestehen. Patchstack hatte am selben Tag, vor dieser Veröffentlichung, festgehalten: „This is not a vulnerability in UpdraftPlus, and as of 19 October no plugin update stops it.“ Beides stimmt in seiner Zeit. Das Update sperrt die alten Schlüssel. Es entfernt kein Plugin und kein Konto, das in den 18 Stunden davor angelegt wurde.

Wie der Angriff funktioniert

UpdraftCentral ist eine Konsole, von der aus eine Agentur viele WordPress-Seiten verwaltet: Updates einspielen, Backups starten, Plugins installieren. Jede verbundene Seite trägt einen Verbindungsschlüssel. Die Konsole signiert ihre Befehle mit ihrem privaten Schlüssel, die Seite prüft die Signatur und führt den Befehl aus. Der Befehl plugin.upload_plugin lädt ein Plugin hoch, installiert und aktiviert es. Das ist keine Lücke, sondern der Zweck der Funktion.

Genau deshalb half keine Prüfung im Plugin. Patchstack schreibt, die Befehle seien „with genuine dashboard private keys“ signiert gewesen; jede Kontrolle, die UpdraftPlus vornimmt, fiel positiv aus. Für die Seite sah der Angriff aus wie ein Administrator, der ein Plugin installiert. Eine WAF vor der Seite sieht dasselbe: eine wohlgeformte, signierte Anfrage an einen legitimen Endpunkt, ohne Angriffsmuster, das eine Regel erkennen könnte. Patchstack nennt zwei Quelladressen, hält aber fest, dass eine Sperre von IP-Adressen hier kein wirksames Mittel ist.

Das installierte Plugin trägt die Beschreibung „Small maintenance toolkit: keeps option storage tidy.“ und wartet auf einen URL-Parameter mit einem Token aus 32 Zeichen. Trifft er ein, legt das Plugin ein verstecktes Konto an, das in der Benutzerliste als Redakteur erscheint, aber die Rechte manage_options und install_plugins trägt, also Administrator ist. Den Besucher meldet es per Cookie an, am Anmeldeformular vorbei; Zwei-Faktor-Authentifizierung und Plugins zum Schutz der Anmeldung kommen gar nicht zum Zug. Das Konto bleibt bestehen, wenn das Plugin gelöscht wird. Die Benutzernamen folgen dem Muster zwei Wörter plus zwei Ziffern, etwa data-ops43, mit einer Adresse unter example.org und dem Anzeigenamen „Site Tools“; in der Datenbank legt die Backdoor die Option _sync_token an.

Wer betroffen ist

Nicht jede Installation von UpdraftPlus, sondern jede Seite, die einen Verbindungsschlüssel zur Cloud-Konsole von UpdraftCentral trägt. Patchstack rät, das auch auf Seiten zu prüfen, auf denen nach eigener Erinnerung nie UpdraftCentral im Einsatz war: Ein Schlüssel aus einem früheren Test oder von einer Vorgängeragentur kann noch in der Datenbank liegen. Nicht betroffen sind selbst gehostete Installationen von UpdraftCentral und, nach Angaben von TeamUpdraft, Nutzer der freien Version ohne Konto bei teamupdraft.com.

Zwei Nebenwirkungen betreffen auch Seiten ohne Backdoor. Alle Verbindungen zu UpdraftVault wurden getrennt; bis zur erneuten Verbindung kommt dort kein Backup mehr an. Alle Schlüssel von UpdraftClone wurden ersetzt; wer Schlüssel an Kunden weitergegeben hat, muss die neuen aus seinem Konto weiterreichen. Und jeder Inhaber eines Kontos bei teamupdraft.com soll sein Passwort ändern, die Adresse dafür von Hand eingeben statt einem Link zu folgen, dasselbe Passwort überall sonst ersetzen und die Zwei-Faktor-Authentifizierung neu einrichten.

Was Sie jetzt prüfen

Für eine Agentur mit zwanzig oder zweihundert Kundenseiten ist das eine Liste, die je Seite abgearbeitet und festgehalten wird. Die Reihenfolge ist wichtig: erst der Schlüssel, dann das Plugin, dann die Konten, dann Passwörter und Sitzungen. Melden Sie sich dafür direkt an der jeweiligen Seite an, nicht über UpdraftCentral.

1. Inventar. Auf jeder Seite, auch auf solchen ohne bekannte Fernwartung: wp option get updraft_central_localkeys. Steht dort ein Schlüssel, ist die Seite auf der Liste.
2. Schlüssel löschen. In der Oberfläche unter Einstellungen, UpdraftPlus, Erweiterte Werkzeuge, UpdraftCentral, oder mit wp option delete updraft_central_localkeys. Die Seite nur aus der Konsole zu entfernen reicht nach Patchstack nicht; der Schlüssel auf der Seite bleibt sonst gültig.
3. Aktualisieren. Auf UpdraftPlus 1.26.13 oder 2.26.13. Das Update trennt die alten Verbindungen, räumt aber nichts auf, was schon installiert ist.
4. Plugins prüfen, auch den Reiter Must-Use. Suchen Sie nach der Beschreibung „Small maintenance toolkit: keeps option storage tidy.“, nicht nach einem Namen; der wechselt. Ein Fund wird deaktiviert und aus dem Webroot verschoben, die Option _sync_token gelöscht.
5. Benutzer prüfen. Unbekannte Administratoren, dazu Redakteure mit zusätzlichen Rechten, Benutzernamen nach dem Muster zwei Wörter plus zwei Ziffern, Adressen unter example.org, Anzeigename „Site Tools“. In den Zugriffsprotokollen: der Parameter mit dem 32-stelligen Token und Anfragen mit einem User-Agent ohne die Versionsnummer und Adresse, die echter UpdraftCentral-Verkehr mitschickt.
6. Passwörter und Sitzungen. Alle Administratorpasswörter ändern, offene Sitzungen beenden, Zwei-Faktor-Authentifizierung einschalten. Zeigt sich das Konto oder der Token im Protokoll, gilt die Seite nach Patchstack als vollständig kompromittiert: Wiederherstellung aus einem Backup von vor dem 17. Oktober, danach die Liste von vorn.
7. Speicherzugänge. Den Backup-Speicher neu autorisieren und dessen Zugangsschlüssel ändern, „as a precaution“, wie TeamUpdraft schreibt. UpdraftVault neu verbinden und ein manuelles Backup laufen lassen; neue UpdraftClone-Schlüssel an Kunden weitergeben.
8. Festhalten und informieren. Je Seite: Datum, Schlüssel gefunden oder nicht, Backdoor gefunden oder nicht, Schritte, Dauer. Daraus entsteht die Nachricht an den Kunden und der Nachweis für den Wartungsvertrag, wie ihn der Beitrag zu Wartung und Betrieb beschreibt.

Fernwartung mit weniger Rechten

Der Vorfall zeigt, was ein Fernwartungsschlüssel ist: Administratorzugang zu jeder verbundenen Seite, hinterlegt an einer Stelle, die nicht Ihnen gehört. Die Datenbank des Herstellers wurde damit zur gemeinsamen Schwachstelle aller verbundenen Seiten. Das gilt nicht nur für UpdraftCentral, sondern für jede Konsole, die Befehle an viele Seiten schickt.

Vier Regeln machen den Schaden im nächsten Fall kleiner. Erstens ein Inventar: Welche Fernwartungen sind mit welchen Kundenseiten verbunden, wer hält die Schlüssel, seit wann. Zweitens die geringsten Rechte: Patchstack rät, einen Schlüssel, wenn er sein muss, unter einem Konto anzulegen, das keine Plugins installieren darf. Updates und Backups brauchen diese Rechte nicht. Drittens getrennte Konten je Zweck und eine Rotation, wenn Mitarbeitende gehen oder ein Anbieter einen Vorfall meldet. Viertens Abstand zwischen Verwaltungsebene und öffentlicher Seite: Je weniger eine öffentlich erreichbare Seite selbst installieren und ändern kann, desto weniger kann ein gestohlener Schlüssel dort anrichten. Dass die Backups in eigenem Speicher unberührt blieben, zeigt den Wert derselben Trennung auf der anderen Seite.

Was das für Kunden von obhut heißt

Eine Website, die als statische Dateien exportiert und bei obhut ausgeliefert wird, hat auf ihrer öffentlichen Oberfläche kein wp-admin, keinen Plugin-Installer und keinen Endpunkt für Fernwartung. Ein Befehl wie plugin.upload_plugin findet dort nichts, was ihn ausführt. Das Redaktionssystem läuft dann nur noch dort, wo redigiert wird, und muss nicht öffentlich erreichbar sein. Was ein solcher Export vor der Veröffentlichung braucht, steht im Launch-Check; wie obhut die Dateien ausliefert, auf der Seite zum Hosting für Agenturen.

Läuft ein WordPress hinter dem Proxy von obhut, bleibt all das an seinem Origin bestehen. Die WAF von obhut kann einen korrekt signierten UpdraftCentral-Befehl nicht von einem legitimen unterscheiden; es ist derselbe Befehl, nur von der falschen Hand abgeschickt. Die Korrektur liegt deshalb auf der Seite, beim Schlüssel und bei den Rechten, nicht am Edge.

Häufige Fragen

Ich habe UpdraftCentral nie benutzt. Muss ich etwas tun?

Prüfen Sie es trotzdem mit wp option get updraft_central_localkeys. Liegt kein Schlüssel vor, bleibt das Update auf 1.26.13 oder 2.26.13. Haben Sie ein Konto bei teamupdraft.com, ändern Sie dessen Passwort und richten die Zwei-Faktor-Authentifizierung neu ein.

Reicht das Plugin-Update?

Nein. Das Update trennt Verbindungen, die vor dem 18. Oktober, 13:07 Uhr britischer Zeit, bestanden, und sperrt damit die alten Schlüssel. Ein Plugin oder Konto, das zwischen dem 18. und 19. Oktober angelegt wurde, bleibt, bis Sie es entfernen.

Hätte eine WAF oder Zwei-Faktor-Authentifizierung den Angriff verhindert?

Nein. Der Befehl kam korrekt signiert über den vorgesehenen Kanal; für eine WAF ist das legitimer Verkehr. Die Backdoor meldet ihren Besucher per Cookie an, ohne das Anmeldeformular zu berühren, sodass die Zwei-Faktor-Prüfung nie läuft. Gewirkt hätten nur ein fehlender Schlüssel oder ein Schlüssel ohne das Recht, Plugins zu installieren.

Soll ich die Seiten wieder mit UpdraftCentral verbinden?

TeamUpdraft beschreibt die erneute Verbindung als letzten Schritt nach der Bereinigung. Patchstack rät, damit zu warten, bis der Hersteller die Ursache erklärt hat, und einen neuen Schlüssel dann unter einem Konto ohne install_plugins anzulegen. Entscheiden Sie das je Kunde und halten Sie die Entscheidung fest.