Kurz gesagt

  • Ein ungepflegtes WordPress blieb acht Wochen unbemerkt gehackt; auf demselben Server lagen weitere Websites mit Hintertüren.
  • Kritische Lücken werden 2026 am Tag der Veröffentlichung ausgenutzt. Updates gehören in jede Nacht, nicht ins Quartal.
  • WordPress gehört auf einen eigenen Server, nicht neben den Shop mit seinen Kundendaten.
  • Backups gehören verschlüsselt an zwei andere Orte. Das kostet weniger als zehn Euro im Monat.

Ein Einbruch, der acht Wochen niemandem auffiel

Ende September meldete sich ein Kunde: Auf seiner WordPress-Website standen 94 Casino-Beiträge, veröffentlicht seit Anfang August über ein Administratorkonto, das niemand angelegt hatte. Google hatte die Seiten bereits im Index. Die Website war vor Jahren eingerichtet worden. Eine laufende Pflege war nie beauftragt, Updates spielte niemand ein.

Bei der Prüfung fanden wir mehr: weitere fremde Administratorkonten, verdächtige Plugin-Dateien und PHP-Hintertüren im Upload-Verzeichnis. Eine zweite WordPress-Website auf demselben Server zeigte dasselbe Muster, eine dritte enthielt ältere Hintertüren. Schon der Zugang kostete Zeit: Aktuelle Zugangsdaten hatte niemand mehr, und der Bestätigungscode des Hosting-Kontos ging an eine dritte Person. Bis wir handeln konnten, vergingen drei Tage.

Unsere Empfehlung war, nichts zu reparieren. Wer Hintertüren hinterlegt hat, hinterlegt sie an mehreren Stellen. Sicherheitsforscher haben gerade eine WordPress-Hintertür beschrieben, die sich nach dem Löschen aus Dateien, Datenbank und Arbeitsspeicher selbst wiederherstellt. Ein solcher Server gilt als kompromittiert. Wir haben die betroffenen Installationen gelöscht, die Spam-Adressen antworten mit „410 Gone“, damit Google sie schneller entfernt, und benötigte Websites ziehen auf einen neuen Server.

Hätte auf diesem Server ein Onlineshop gelegen, wäre er mit betroffen gewesen. Wer PHP-Code auf einem Server ausführt, kann in der Regel auch die Konfiguration der Nachbaranwendungen lesen: Datenbankzugänge, API-Schlüssel, Zahlungsanbindungen. Dann geht es nicht mehr um Spam, sondern um Kundendaten. Eine solche Datenpanne ist binnen 72 Stunden der Aufsichtsbehörde zu melden.

2026 in Zahlen: Lücken werden in Stunden ausgenutzt

Das Risiko liegt selten in WordPress selbst, sondern in der Zeit zwischen Sicherheitsupdate und Installation. Drei Beispiele aus diesem Jahr:

Wer Updates einmal im Quartal einspielt, ist bei solchen Lücken wochenlang offen. Und jedes Plugin, jedes Theme ist ein eigenes Update.

Der andere Fall: Blog vom Shop getrennt

Bei einem Fachhändler lief der Blog auf dem Produktivserver des Shopware-Shops, neben Entwicklungsumgebungen und weiteren Anwendungen. Der Blog liefert die Beiträge, die im Shop erscheinen; öffentlich gelesen wird er dort, nicht auf seiner eigenen Adresse. Im August haben wir ihn auf einen eigenen kleinen Server umgezogen. Das Vorgehen:

  1. Umzug ohne Risiko für den Altbestand: Dateien und Datenbank gingen direkt vom alten auf den neuen Server, der alte Blog blieb bis zur Abnahme unverändert. Vor der Umstellung haben wir Seiten, Beiträge und Darstellung beider Installationen verglichen.
  2. Aktuelle Software: WordPress, PHP und Datenbank auf dem aktuellen Stand; vorher lief eine ältere WordPress-Version.
  3. Weniger Angriffsfläche: Anmeldung, Verwaltung und Schnittstelle sind nur für den Shopserver und die Adressen des Kunden und unseres Teams erreichbar. Öffentliche Seitenaufrufe leiten in den Shop weiter, alles andere wird abgewiesen. Datei-Bearbeitung im Admin-Bereich und XML-RPC sind abgeschaltet.
  4. Code nicht beschreibbar: WordPress selbst kann seine Programmdateien nicht ändern; Updates installiert ein eigenes Wartungskonto. Im Upload-Verzeichnis werden PHP-Dateien nicht ausgeführt. Genau dort legen Angreifer ihre Hintertüren ab, wie bei Elementor Pro.
  5. Server-Grundschutz: Firewall mit geschlossenem Standard, Sperre nach Fehlversuchen, SSH nur mit Schlüssel, automatische Sicherheitsupdates des Betriebssystems.

Für Lücken wie die vom September heißt das: Aufrufe aus dem Internet kommen auf diesem Server gar nicht erst bei WordPress an. Geschlossen war sie trotzdem in der folgenden Nacht.

Updates jede Nacht, mit Rückweg

Ein Zeitplan auf dem Server prüft jede Nacht, ob Updates für WordPress, Plugins, Themes oder Übersetzungen vorliegen. Gibt es keine, passiert nichts. Gibt es welche, läuft immer derselbe Ablauf:

  1. Datenbank und betroffene Dateien werden vorher gesichert.
  2. Die Updates werden installiert.
  3. Die Installation wird gegen die offiziellen Prüfsummen geprüft und die Website aufgerufen.
  4. Wir erhalten eine Nachricht mit allen Änderungen, bei einem Fehler mit dem Weg zurück.

Im September gab es so in 16 von 30 Nächten Updates. Das WordPress-Sicherheitsupdate 7.1.2 vom 22. September war am 23. September um 4:17 Uhr installiert. Große Versionssprünge und Erweiterungen ohne Update-Kanal spielen wir bewusst von Hand ein.

Backups: verschlüsselt, inkrementell, an zwei Orten

Vorher legte ein Backup-Plugin seine Archive im Upload-Verzeichnis der Website ab, also auf demselben Server, der geschützt werden sollte. 20 Archive belegten dort knapp 16 GB. Fällt der Server aus oder wird er übernommen, sind solche Sicherungen mit betroffen.

Heute läuft das Backup außerhalb von WordPress:

  • Jede Nacht entsteht ein konsistenter, geprüfter Datenbank-Export mit Prüfsumme.
  • Datenbank, Website-Dateien und Serverkonfiguration gehen verschlüsselt an zwei getrennte Speicher in Deutschland und Finnland, jeweils mit eigenem Schlüssel. Der Speicheranbieter sieht nur verschlüsselte Daten.
  • Die Sicherung ist inkrementell und dedupliziert: Übertragen wird nur, was sich geändert hat. 14 Tages-, 8 Wochen- und 12 Monatsstände bleiben erhalten.
  • Jede Woche werden beide Speicher geprüft. Fehlt eine Sicherung, meldet sich die Überwachung.

Ein Backup ist erst etwas wert, wenn die Wiederherstellung geklappt hat. Deshalb haben wir die Website aus der Sicherung vollständig auf einem leeren Server wiederhergestellt und geprüft. Der Ablauf ist Schritt für Schritt festgehalten, damit er im Ernstfall nicht von einer Person abhängt.

Die Kosten sind gering: Ein Speicher mit 1 TB kostet bei einem deutschen Anbieter rund 3 bis 4 Euro im Monat. Zwei Standorte für weniger als zehn Euro, dazu ein kleiner eigener Server für WordPress.

Was Sie prüfen sollten

  • Läuft WordPress auf demselben Server wie Ihr Shop oder andere Anwendungen mit Kundendaten?
  • Wer spielt Updates ein, und wann zuletzt?
  • Liegen Ihre Backups auf einem anderen Server, an einem anderen Ort, verschlüsselt?
  • Wurde eine Wiederherstellung schon einmal ausprobiert?
  • Hat jemand aktuelle Zugangsdaten zu Hosting, Server und WordPress, und kommt er im Notfall auch an die Bestätigungscodes?

Wenn Sie eine Frage nicht sicher beantworten können, sehen wir uns Ihre Installation gerne an. WordPress-Pflege ›