Hoster gehackt: was Sie in WordPress und WooCommerce jetzt ändern müssen

Am 23. Oktober 2026 hat der US-Hoster DreamHost festgestellt, dass Unbefugte den Server seines webbasierten File Managers übernommen hatten. Abgeflossen sind FTP/SFTP-Zugangsdaten, möglicherweise auch Webmail-Sitzungen, Dateien und E-Mails. Für eine WordPress-Website ist SFTP-Zugriff gleichbedeutend mit Lesezugriff auf wp-config.php, also auf Datenbankpasswort, Schlüssel und Salts. Ich beschreibe hier, was DreamHost bestätigt hat, in welcher Reihenfolge ich nach so einem Vorfall Zugänge und Schlüssel erneuere, wie ich mit WP-CLI auf Veränderungen prüfe und was Sie als Shopbetreiber in Deutschland nach der DSGVO melden müssen. Die Liste passt auf jeden Hoster.

#Was ist bei DreamHost im Oktober 2026 passiert?

Die Fakten stammen aus der Mitteilung von DreamHost vom 29. Oktober 2026, dem Musterschreiben an Kunden, das DreamHost am 2. November 2026 bei der Generalstaatsanwaltschaft Kaliforniens eingereicht hat, und dem Bericht von Zack Whittaker bei TechCrunch vom 4. November 2026.

Der Angriffsweg lief über den File Manager unter files.dreamhost.com, der auf Software eines Drittanbieters aufbaut. Im Schreiben heißt es, der Angreifer habe “eine Schwachstelle in dieser Software ausgenutzt” (eigene Übersetzung). Welches Produkt und welche Lücke, sagt DreamHost nicht; laut TechCrunch wollte ein Sprecher das nicht nennen. DreamHost betont außerdem, der Vorfall habe nichts mit den jüngsten PHP-Updates auf den Servern zu tun.

Betroffen sind laut Schreiben die FTP/SFTP-Benutzernamen und Passwörter von Personen, die sich zwischen etwa August 2026 und dem 23. Oktober 2026 im File Manager angemeldet haben. Beim Webmail unterscheiden sich die beiden DreamHost-Texte: Das Kundenschreiben spricht von Sitzungsinformationen “einer begrenzten Zahl von Webmail-Nutzern”, die Mitteilung von Webmail-Zugangsdaten. In wenigen Fällen könnten Postfachinhalte eingesehen worden sein. Das Schreiben ergänzt, auch E-Mail-Inhalte und Dateien auf dem FTP/SFTP-Server “könnten ebenfalls abgerufen worden sein” (eigene Übersetzung).

Nicht betroffen sind nach DreamHost die Anmeldedaten für das Kontrollpanel und die Zahlungsdaten; vollständige Kartennummern speichert DreamHost nicht. Zum Umfang sagt die Mitteilung “deutlich unter etwa 10 %” der E-Mail- und FTP/SFTP-Konten (eigene Übersetzung). Eine genaue Zahl nennt weder DreamHost noch die Meldung in Kalifornien. TechCrunch titelt mit einem “monatelangen Angriff” und gestohlenen Dateien und Postfächern; DreamHost selbst formuliert vorsichtiger mit “könnten”. Ob der Angreifer ab Mitte August im System war oder ob ab dann nur Zugangsdaten mitgeschnitten wurden, ist offen.

Datenbankpasswörter, SSH-Zugänge und API-Schlüssel erwähnt DreamHost nicht. Bei WordPress ist das kein Entwarnungssignal. Wer per SFTP auf die Dateien einer Installation kommt, kann wp-config.php öffnen, und dort stehen das MySQL-Passwort, die Schlüssel und die Salts. Diese Folgerung ist meine, DreamHost hat sie nicht getroffen.

#Was verlangt DreamHost von seinen Kunden?

DreamHost bittet Kunden:

• die Passwörter im Kontrollpanel (panel.dreamhost.com) zu ändern; das kann nur der Kontoinhaber, und die Änderung kann bis zu 15 Minuten dauern,
• FTP/SFTP-Zugangsdaten, die im betroffenen Zeitraum im File Manager benutzt wurden, als kompromittiert zu behandeln und dasselbe oder ein ähnliches Passwort auch überall sonst zu ändern,
• E-Mail-, FTP- und SFTP-Programme mit dem neuen Passwort zu aktualisieren,
• die Website-Dateien auf unerwartete Änderungen zu prüfen,
• in den E-Mail-Konten Weiterleitungsregeln und Filter auf unbekannte Änderungen zu prüfen,
• zu überlegen, ob Inhalte von E-Mails oder Dateien Zugang zu weiteren Konten geben, und diese ebenfalls zu prüfen.

DreamHost fragt nach eigener Aussage nie per E-Mail nach Passwörtern; unaufgeforderte Reset-Mails sollen Sie ignorieren. Gehen Sie für Änderungen immer selbst ins Panel, statt einem Link aus einer Mail zu folgen.

#In welcher Reihenfolge erneuere ich Zugänge nach einem Einbruch beim Hoster?

Die Reihenfolge ist wichtig, weil jeder spätere Schritt auf den früheren aufbaut. Ein neues Datenbankpasswort nützt wenig, wenn der Angreifer per SFTP die neue wp-config.php gleich wieder liest. Ein neues SFTP-Passwort nützt wenig, wenn ein Trojaner auf Ihrem Rechner die Eingabe mitschneidet. Die WordPress-Dokumentation zu gehackten Websites empfiehlt, alle Zugänge zu ändern (FTP/SFTP, wp-admin, das Hoster-Panel und MySQL) für alle Nutzer mit Zugriff, und den lokalen Rechner zu scannen, weil Trojaner FTP- und Admin-Logins abgreifen.

Zum letzten Schritt schreibt die WordPress-Dokumentation: Ändern Sie die Passwörter, nachdem Sie sichergestellt haben, dass die Website sauber ist; wenn Sie sie nur bei der Entdeckung geändert haben, ändern Sie sie jetzt noch einmal (sinngemäß, eigene Übersetzung).

#Wie ändere ich das Datenbankpasswort, ohne die Website lahmzulegen?

Die WordPress-Dokumentation empfiehlt, Datenbankbenutzer und Passwort zu ändern und den neuen Wert in wp-config.php einzutragen. Die Reihenfolge, mit der ich Ausfälle kurz halte:

1. Im Panel des Hosters das Passwort des Datenbankbenutzers ändern. Ab jetzt zeigt die Website einen Verbindungsfehler.
2. Sofort per SSH den neuen Wert setzen, ohne die Datei per Hand zu öffnen:

wp config set DB_PASSWORD 'NEUES_PASSWORT' --type=constant

3. Prüfen, ob die Verbindung steht:

wp db check

Wenn Ihr Hoster es erlaubt, legen Sie besser einen neuen Datenbankbenutzer mit neuem Namen an, geben ihm die Rechte auf die Datenbank, stellen wp-config.php um und löschen danach den alten Benutzer. Dann gibt es keine Minute ohne Verbindung. Achten Sie darauf, dass das Passwort nicht in der Shell-History landet; auf manchen Systemen hilft ein Leerzeichen vor dem Befehl.

#Wie erneuere ich die Salts und was passiert dabei?

Schlüssel und Salts in wp-config.php sichern die Anmelde-Cookies. Die Dokumentation zu wp-config.php sagt, Sie können sie jederzeit ändern, um alle bestehenden Cookies ungültig zu machen; alle Nutzer müssen sich dann neu anmelden. Genau das wollen Sie nach einem Einbruch: Ein Angreifer mit kopiertem Cookie oder mit den alten Salts fliegt raus.

Mit WP-CLI ist das ein Befehl:

wp config shuffle-salts

Ohne SSH holen Sie neue Werte vom Salt-Generator von WordPress.org und ersetzen die acht Zeilen in wp-config.php. Bei einem Shop müssen sich danach auch Kunden mit Konto neu anmelden. Ich lege den Schritt deshalb in eine ruhige Stunde, aber auf denselben Tag.

#Wie finde ich fremde Administratoren und Anwendungspasswörter?

Ein Angreifer mit Datenbankzugriff kann sich selbst einen Administrator anlegen. Den finden Sie mit wp user list:

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

Sehen Sie sich das Feld user_registered genau an. Ein Admin, der im Zeitraum des Vorfalls angelegt wurde und den niemand kennt, ist ein starkes Zeichen für einen Einbruch. Löschen Sie ihn nicht sofort, sondern notieren Sie Login, E-Mail und Datum für die Dokumentation, dann entfernen Sie ihn.

Anwendungspasswörter sind eigene Zugangsdaten für die REST-API, die neben dem normalen Passwort bestehen. Laut Integrationsleitfaden speichert WordPress zu jedem Anwendungspasswort Datum und IP-Adresse der letzten Nutzung, auf etwa 24 Stunden genau. Mit WP-CLI prüfen und widerrufen Sie sie pro Benutzer:

wp user application-password list 1
wp user application-password delete 1 <uuid>

Ohne WP-CLI finden Sie sie im Backend unter Benutzer, Profil bearbeiten, ganz unten. Was Sie nicht zuordnen können, wird widerrufen. Integrationen, die ein Anwendungspasswort brauchen, bekommen danach ein neues.

#Welche WooCommerce- und Stripe-Schlüssel muss ich erneuern?

Alles, was in der Datenbank oder in Dateien stand, gilt als bekannt. Bei einem WooCommerce-Shop sind das mindestens die REST-API-Schlüssel und die Schlüssel des Zahlungsanbieters.

Die WooCommerce-REST-API-Schlüssel finden Sie unter WooCommerce, Einstellungen, Erweitert, REST-API. Dort widerrufen Sie jeden Schlüssel mit “Revoke Key” und erzeugen für jede Anbindung (Warenwirtschaft, Versandtool, Marktplatz-Connector) einen neuen. Ich lege dafür vorher eine Liste an, welche Integration welchen Schlüssel nutzt, sonst sucht man nach dem Widerruf, warum die Bestellungen nicht mehr in die Warenwirtschaft laufen.

Für Stripe gelten laut Stripe-Dokumentation zu API-Schlüsseln und zu Webhooks diese Regeln:

Die siebentägige Frist ist für den Normalbetrieb gedacht, damit nichts ausfällt. Nach einem Einbruch bedeutet sie sieben Tage, in denen auch der Angreifer den alten Schlüssel nutzen kann. Ich trage deshalb erst den neuen Schlüssel in WooCommerce ein, teste eine Zahlung im Testmodus oder eine kleine echte Zahlung und lasse den alten Schlüssel dann sofort auslaufen. Stripe bietet für Live-Schlüssel außerdem Zugriffsrichtlinien nach IP-Adresse oder Netz an. Wenn Ihr Shop feste ausgehende IPs hat, lohnt sich das.

#Was mache ich mit E-Mail-Konten und Weiterleitungen?

Bei DreamHost waren Webmail-Sitzungen betroffen, und DreamHost bittet ausdrücklich, Weiterleitungsregeln und Filter zu prüfen. Eine unauffällige Regel, die Mails mit “Passwort” im Betreff an eine fremde Adresse kopiert, überlebt jeden Passwortwechsel des Postfachs.

Prüfen Sie in jedem Postfach, das zur Website gehört (admin@, shop@, info@ und die Adresse des WordPress-Admins):

• Passwort ändern und gespeicherte Passwörter in Mailprogrammen und auf Smartphones aktualisieren,
• Weiterleitungen und automatische Antworten auf unbekannte Ziele prüfen,
• Filter auf Regeln prüfen, die Mails löschen, verschieben oder weiterleiten,
• im Postfach selbst nach Zugangsdaten suchen, die per Mail verschickt wurden, etwa Zugänge zu Zahlungsanbietern, Domain-Registraren oder Agentur-Tools, und diese ebenfalls ändern.

#Wie prüfe ich, ob WordPress-Dateien verändert wurden?

Für den Core vergleicht wp core verify-checksums Ihre Dateien mit den Prüfsummen von WordPress.org. Mit —include-root meldet der Befehl zusätzlich Dateien im Hauptverzeichnis, die nicht zu WordPress gehören:

wp core verify-checksums --include-root

Für Plugins aus dem WordPress.org-Verzeichnis gibt es wp plugin verify-checksums. Mit —strict werden auch geänderte Readme-Dateien gemeldet:

wp plugin verify-checksums --all

Der Abgleich läuft gegen die Prüfsummen von WordPress.org. Premium-Plugins, gekaufte Themes und Eigenentwicklungen deckt er deshalb nicht ab. Diese vergleiche ich mit einer frischen Kopie vom Hersteller oder mit dem Stand im Git-Repository.

Von Hand schaue ich mir die Dateien an, die die WordPress-Dokumentation nennt: .htaccess im Hauptverzeichnis und in Unterverzeichnissen, index.php, header.php, footer.php und functions.php des aktiven Themes. Die Verzeichnisse /wp-admin und /wp-includes ersetze ich durch frische Kopien derselben WordPress-Version. Findet sich dabei Schadcode, ist das kein Fall mehr für eine Checkliste. Dann gehen Sie nach meiner Anleitung zur Bereinigung einer gehackten WordPress-Website vor und ändern die Passwörter nach der Bereinigung ein zweites Mal.

#Muss ich den Einbruch beim Hoster nach DSGVO melden?

Rechtlich ist der Hoster Ihr Auftragsverarbeiter und Sie sind als Shopbetreiber der Verantwortliche. Die Meldepflicht gegenüber Behörde und Kunden liegt bei Ihnen, nicht beim Hoster. Die Artikel der DSGVO, die hier greifen:

Wann läuft die 72-Stunden-Frist? Der Europäische Datenschutzausschuss schreibt in den Leitlinien 9/2022, Randnummer 44, der Verantwortliche sei grundsätzlich als “informiert” anzusehen, sobald der Auftragsverarbeiter ihn über die Verletzung unterrichtet hat (eigene Übersetzung). Nach Randnummer 31 bedeutet “bekannt”, dass mit hinreichender Sicherheit ein Sicherheitsvorfall vorliegt, der personenbezogene Daten betrifft. Der Auftragsverarbeiter bewertet das Risiko nicht, das tun Sie.

Für einen DreamHost-Kunden heißt das nach meiner Lesart: Die Uhr beginnt grundsätzlich mit der Nachricht von DreamHost, also mit der Reset-Mail vom 23. bis 25. Oktober oder mit dem Kundenschreiben, nicht am 15. August. Ob Sie melden müssen, hängt von Ihrer Bewertung ab. SFTP-Zugangsdaten, mit denen wp-config.php und damit die WooCommerce-Datenbank mit Namen, Adressen und Bestellhistorie erreichbar waren, sprechen für eine meldepflichtige Verletzung. Eine Visitenkarten-Website ohne personenbezogene Daten braucht womöglich nur den internen Eintrag nach Art. 33 Abs. 5. Das ist meine Einschätzung und kein Urteil einer Behörde zu diesem Fall. Bei einem Shop mit Kundenkonten würde ich im Zweifel melden und die Meldung bei Bedarf ergänzen.

#Bei welcher Behörde melde ich in Deutschland?

Für die meisten Shops ist der Bundesbeauftragte nicht zuständig. Der BfDI schreibt auf seiner Meldeseite: “Privatunternehmen werden meist von den Landesbehörden beaufsichtigt, es gibt jedoch einige Ausnahmen.” In seiner Liste der Landesdatenschutzbehörden heißt es, der nicht-öffentliche Bereich werde grundsätzlich von den Landesdatenschutzbehörden betreut. Ihr Onlineshop meldet also an die Aufsichtsbehörde des Bundeslandes, in dem Ihr Unternehmen sitzt.

Für Shops in Österreich gelten dieselben DSGVO-Artikel und dieselbe 72-Stunden-Frist. Die österreichische Meldestelle und ihr Verfahren habe ich für diesen Beitrag nicht geprüft; schauen Sie dort direkt nach, bevor die Frist läuft.

Was in die Dokumentation nach Art. 33 Abs. 5 gehört, halte ich in einer einfachen Tabelle fest: Datum und Uhrzeit der Nachricht des Hosters, betroffene Zugänge, betroffene Datenkategorien (Kundenkonten, Bestellungen, Adressen), Ergebnis der Prüfung mit WP-CLI, jede geänderte Zugangsdatenart mit Datum, die Risikobewertung mit Begründung und die Entscheidung für oder gegen eine Meldung.

#Was bleibt beim DreamHost-Vorfall offen?

• Welche Drittanbieter-Software den File Manager stellte und welche Lücke ausgenutzt wurde, hat DreamHost nicht genannt.
• Ob Datenbankpasswörter, Inhalte von wp-config.php oder SSH-Schlüssel tatsächlich gelesen wurden, sagt DreamHost nicht; Dateien auf dem FTP/SFTP-Server “könnten” abgerufen worden sein.
• Wie viele Kunden betroffen sind, steht nirgends genau; DreamHost nennt nur “deutlich unter 10 %”.
• Ob der Angreifer ab Mitte August im System war oder Zugangsdaten nur ab dann mitgeschnitten wurden, ist offen.
• Beim Webmail widersprechen sich zwei DreamHost-Texte: Sitzungsinformationen im Kundenschreiben, Zugangsdaten in der Mitteilung.

#Was ist Ihr nächster Schritt?

Gehen Sie die Tabelle mit den elf Schritten heute von oben nach unten durch und notieren Sie zu jedem Schritt Datum und Uhrzeit; das ist zugleich Ihre Dokumentation nach Art. 33 Abs. 5. Wenn Sie keinen SSH-Zugang haben oder WP-CLI nicht nutzen, oder wenn die Prüfsummen Abweichungen zeigen, übernehme ich die Prüfung und die Rotation der Schlüssel. Für WooCommerce-Shops finden Sie mich auf meiner Seite als WooCommerce-Entwickler. Wenn Ihr Shop auf Shopify läuft und nur die angebundene WordPress-Website beim Hoster lag, schauen Sie auf meine Seite als Shopify-Entwickler.