WordPress gehackt: Die ersten drei Stunden – und wie es nicht wieder passiert

Der Anruf klingt fast immer gleich: „Ein Kunde hat mich angerufen, bei ihm kommt eine fremde Seite.“ Bei uns steht dann als Erstes nicht das Aufräumen, sondern das Sichern. Denn wer sofort löscht, vernichtet die Spuren, die zeigen, wie der Angreifer hereingekommen ist – und macht damit ziemlich sicher, dass er wieder hereinkommt. Dieser Beitrag beschreibt den Ablauf für den Ernstfall. Wie Sie eine gesunde Seite gesund halten, steht im Ratgeber WordPress absichern & aktuell halten. Geht es um den Rechner im Büro und nicht um die Website, sind Sie im Beitrag Computer gehackt? richtig.

1. Woran Sie merken, dass die Seite übernommen wurde

Ein Angreifer, der eine Firmenwebsite kapert, will sie in der Regel nicht zerstören, sondern unbemerkt benutzen – für Weiterleitungen, Spam-Seiten oder Mailversand. Deshalb sieht die Startseite oft völlig normal aus, wenn Sie als angemeldeter Redakteur draufschauen. Diese Zeichen sprechen für eine Übernahme:

Ein einzelnes Zeichen kann eine harmlose Ursache haben – ein langsamer Server, ein verunglücktes Update. Treten zwei davon gemeinsam auf, behandeln Sie die Seite bis zum Beweis des Gegenteils als kompromittiert.

2. Die ersten drei Stunden: Sofortmaßnahmen in der richtigen Reihenfolge

Die Reihenfolge ist hier wichtiger als das Tempo. Wer zuerst löscht und dann nachdenkt, hat keine Grundlage mehr für die Frage, wie der Angreifer hereingekommen ist.

1. Beweise sichern (Stunde 1). Vollständige Kopie aller Dateien – mitsamt Zeitstempeln, nicht über ein Werkzeug, das die Daten neu setzt. Dazu ein Datenbank-Dump, die Zugriffs- und Fehlerprotokolle des Servers, die Mail-Protokolle und eine Dateiliste sortiert nach Änderungsdatum. Gerade diese Liste sagt oft in zwei Minuten, an welchem Tag der Einbruch passiert ist.
2. Seite vom Netz nehmen (Stunde 1). Erst jetzt: Wartungsmodus oder eine statische Hinweisseite. Solange die Seite weiterläuft, verschickt sie möglicherweise Spam, verteilt Schadcode an Ihre Besucher und sammelt weitere Safe-Browsing-Meldungen ein. Eine ehrliche Zeile genügt: „Diese Website wird derzeit gewartet. Sie erreichen uns unter …“
3. Alle Passwörter wechseln (Stunde 2). WordPress-Administratoren, FTP- und SFTP-Konten, Datenbankbenutzer, Hosting-Panel, DNS-Verwaltung und die E-Mail-Postfächer der Domain. Danach in WordPress alle angemeldeten Sitzungen beenden und die Sicherheitsschlüssel in der Konfigurationsdatei erneuern, damit bestehende Anmelde-Cookies ungültig werden. Neue Passwörter nie über den betroffenen Rechner und nie per Mail verschicken.
4. Hoster informieren (Stunde 2). Der Provider sieht Serverprotokolle, die Sie nicht sehen, kann den Webspace isolieren und weiß, ob auch Nachbarprojekte betroffen sind. Sagen Sie klar, dass es sich um eine Kompromittierung handelt und dass Sie eine Sicherung des Ist-Zustands haben.
5. Betroffene informieren (Stunde 3). Waren Kundendaten im Spiel – Bestellungen, Formulareingänge, Kundenkonten –, ist das ein Fall für die DSGVO: Meldung an die Datenschutzbehörde binnen 72 Stunden ab Kenntnis, Information der Betroffenen bei hohem Risiko. Auch ohne Datenabfluss lohnt eine kurze, sachliche Nachricht an Kunden, die auf der Seite waren.
6. Mitschreiben (durchgehend). Wer hat wann was gemacht? Ein einfaches Protokoll mit Uhrzeiten erspart später Diskussionen und hilft, nichts zu übersehen.

3. Warum „Plugin drüberinstallieren“ nicht reicht

Ein Sicherheits-Plugin findet bekannte Schadmuster. Es findet nicht zuverlässig, was ein Angreifer gezielt in eine bestehende Datei geschrieben hat. Eine saubere Bereinigung prüft deshalb sechs Stellen:

• Die Kern-Dateien gegen das Original. WordPress veröffentlicht zu jedem Paket Prüfsummen; jede abweichende Kern-Datei ist ein Treffer. Wichtig ist dabei die Sprachversion: Eine deutsche Installation aus dem de_DE-Paket hat andere Prüfsummen als das englische Original. Wer das verwechselt, bekommt hunderte Fehlalarme – oder übersieht die eine echte Abweichung.
• PHP-Dateien im Upload-Verzeichnis. In wp-content/uploads/ gehören Bilder und PDFs, sonst nichts. Jede PHP-Datei dort ist bis zum Beweis des Gegenteils eine Hintertür.
• Die .htaccess-Dateien. Nicht nur die im Hauptverzeichnis: Angreifer legen gern zusätzliche Regeln in Unterordnern ab, wo sie niemand sucht. Typisch sind Weiterleitungen, die nur bei bestimmten Besuchern greifen.
• Geplante Aufgaben. Server-Cronjobs und WordPress-eigene Zeitpläne können gelöschte Dateien immer wieder neu anlegen. Wer sie übersieht, bereinigt zweimal dieselbe Seite.
• Die Konfigurationsdatei. In wp-config.php finden sich nach Einbrüchen häufig zusätzliche Zeilen ganz am Anfang oder Ende, weit rechts eingeschoben, damit sie beim Überfliegen nicht auffallen.
• Die Datenbank. In der Tabelle wp_options stehen Werte, die WordPress bei jedem Seitenaufruf ausliest – ein beliebter Platz für nachladenden Code. Dazu kommen fremde Benutzer, veränderte Rollen und untergeschobene Inhalte in Beiträgen.

Erst wenn alle sechs Stellen sauber sind, ist die Seite sauber. Solange eine einzige Hintertür bleibt, ist die nächste Infektion eine Frage von Tagen. Wir gehen diese Punkte im Rahmen eines IT-Sicherheitschecks auch dann durch, wenn nur ein Verdacht besteht.

4. Der aktuelle Anlass: die Core-Lücke wp2shell

2026 gab es erstmals seit Jahren eine kritische Lücke nicht in einem Plugin, sondern im WordPress-Kern selbst. Sie läuft unter dem Namen wp2shell (CVE-2026-63030 und CVE-2026-60137, CVSS 9,8) und erlaubt die Ausführung von fremdem Code ohne Anmeldung – über eine Sammelroute der REST-Schnittstelle in Verbindung mit einer SQL-Injection. Öffentlich bekannt ist sie seit 17.07.2026, und sie wird aktiv ausgenutzt (Rapid7, Wiz; abgerufen 20.09.2026). Technische Details zur Ausnutzung finden Sie hier bewusst nicht – nur, was Sie zur Abwehr brauchen.

Ein Kunde aus der Region hat uns genau deswegen im Sommer angerufen. Der Ablauf war der oben beschriebene: sichern, offline nehmen, Zugangsdaten tauschen, bereinigen, neu aufbauen. Details nennen wir nicht – das ist Sache des Kunden.

Der Kern ist aber nur ein Teil des Bildes. Die meisten Einbrüche laufen weiterhin über Erweiterungen. Allein 2026 betraf das unter anderem Elementor Pro (CVE-2026-32475, behoben in Version 4.2.2, Mitte August 2026), Forminator Forms (CVE-2026-15748) und WooCommerce Wholesale Lead Capture (CVE-2026-27540, CVSS 9,8). Wer eines dieser Plugins einsetzt, prüft die Version gleich mit.

Dazu kommt der Unterbau: PHP 8.1 bekommt seit 31.12.2025 keine Updates mehr, PHP 8.2 erhält nur noch bis 31.12.2026 Sicherheitsupdates, PHP 8.3 bis 31.12.2027 (php.net, abgerufen 20.09.2026). Eine Website auf einer abgelaufenen PHP-Version ist auch dann angreifbar, wenn WordPress selbst aktuell ist. Dass das viele betrifft, zeigt die Verbreitung: WordPress läuft auf 40,2 % aller Websites weltweit und auf 58,8 % aller Websites mit einem Content-Management-System (W3Techs, abgerufen 20.09.2026). Genau deshalb suchen automatisierte Angriffe zuerst dort.

5. Wiederaufbau: sauber neu statt Flickwerk

Ab einer bestimmten Tiefe ist Bereinigen teurer und unsicherer als ein Neuaufbau. Die Faustregel: Sind Kern und Plugins betroffen und liegt der Einbruch länger zurück als die vorhandenen Backups, wird neu aufgebaut. Der Ablauf:

1. Leere Installation. WordPress-Kern frisch von wordpress.org, Themes und Plugins frisch aus der offiziellen Quelle oder vom Hersteller – nie aus dem Backup.
2. Nur Inhalte übernehmen. Aus dem Backup kommen Texte, Bilder, Dokumente und Einstellungen. PHP-Dateien kommen nie aus dem Backup, auch keine scheinbar harmlose Theme-Datei. Bilder werden vorher durchgesehen, Dateien mit PHP-Endung aussortiert.
3. Datenbank prüfen statt blind einspielen. Benutzerliste durchgehen, fremde Konten entfernen, Optionen auf eingeschleusten Code kontrollieren.
4. Neue Zugangsdaten überall. Neuer Datenbankbenutzer, neue Schlüssel in der Konfiguration, neue FTP-Zugänge. Alte Konten löschen, nicht nur das Passwort ändern.
5. Erst testen, dann online. Aufbau auf einer Testumgebung, Funktionsprüfung, dann Umschalten. So ist die Seite nur einmal kurz nicht erreichbar.
6. Google aufräumen. In der Google Search Console die Sicherheitsprobleme ansehen, nach der Bereinigung eine Überprüfung beantragen, Spam-Seiten aus dem Index entfernen lassen und die Sitemap neu einreichen. Bis die Warnung im Browser verschwindet, vergehen erfahrungsgemäß ein bis wenige Tage.
7. Nachkontrolle. Zwei bis vier Wochen später noch einmal Dateien, Benutzer und Protokolle prüfen. Kommt etwas zurück, war eine Hintertür übrig.

Wenn die Seite ohnehin in die Jahre gekommen ist, ist der Zeitpunkt günstig, den Wiederaufbau mit einem Relaunch zu verbinden – statt eine alte Struktur samt ihrer Altlasten zu wiederholen.

6. Was das kostet und wie lange es dauert

Ehrlich gesagt: Das lässt sich erst nach einem Blick auf die Seite seriös beantworten. Der Aufwand hängt davon ab, wie tief der Angreifer gekommen ist, wie viele Plugins im Einsatz sind und ob es ein brauchbares Backup gibt. Diese Größenordnungen sehen wir in der Praxis:

Alle Beträge, die wir dazu nennen, sind Nettobeträge ohne Umsatzsteuer. Wir sehen uns die Seite vorab an und sagen Ihnen vor Beginn, in welche der drei Zeilen Ihr Fall fällt – und was er kostet. Wird es im Lauf der Arbeit mehr, sagen wir es, bevor wir weitermachen.

Nicht eingerechnet ist der Schaden, der nicht auf unserer Rechnung steht: Tage ohne erreichbare Website, verlorene Anfragen, eine Browser-Warnung, die Ihre Kunden gesehen haben. Genau deshalb ist der billigste Teil dieses Beitrags der nächste Abschnitt.

7. Damit es nicht wieder passiert

Kurz, weil das Thema einen eigenen Beitrag hat. Diese sechs Punkte verhindern die weitaus meisten Fälle:

• Updates in Tagen statt Monaten. Kritische Lücken werden innerhalb weniger Tage automatisiert ausgenutzt.
• PHP-Ausführung im Upload-Verzeichnis sperren. Ein Handgriff am Server – und die häufigste Hintertür läuft ins Leere.
• Zwei-Faktor-Anmeldung für alle Administratoren. Ein gestohlenes Passwort genügt dann nicht mehr.
• Backups außerhalb des Web-Verzeichnisses. Eine Sicherung, die auf demselben Webspace liegt, wird mitverschlüsselt oder mitgelöscht. Wie eine tragfähige Sicherung aussieht, steht im Ratgeber Daten sichern: die richtige Backup-Strategie.
• Monitoring. Eine Prüfung, die täglich Erreichbarkeit, Dateiveränderungen und Safe-Browsing-Status meldet, verkürzt die Zeit bis zur Entdeckung von Wochen auf Stunden.
• Testumgebung vor größeren Updates. Damit Aktualisieren nicht als Risiko gilt und deshalb aufgeschoben wird.

Alle sechs Punkte ausführlich, mit Einstellungen und Reihenfolge: WordPress absichern & aktuell halten.

Wie wir Ihnen helfen

Wir übernehmen den ganzen Ablauf: Beweissicherung, Bereinigung oder Neuaufbau, Wiederherstellung bei Google und die Absicherung danach. Sie bekommen vorab eine Einschätzung, wie tief der Fall geht, und nach Abschluss einen kurzen schriftlichen Bericht – was gefunden wurde, was geändert wurde, was offenbleibt. Damit es nicht wieder passiert, betreuen wir Websites auch laufend mit Updates, Backups und Monitoring; der Rahmen dafür steht im Ratgeber IT-Betreuung für KMU. Im akuten Fall ist der schnellste Weg der Anruf – wir sind in Großwilfersdorf und betreuen Betriebe in der ganzen Oststeiermark.

Quellen

• Rapid7: ETR: CVE-2026-63030 (wp2shell) – Critical Remote Code Execution in WordPress Core (abgerufen 20.09.2026) – CVE-2026-63030 und CVE-2026-60137, CVSS 9,8, öffentlich seit 17.07.2026, aktive Ausnutzung.
• Wiz: wp2shell – CVE-2026-63030, CVE-2026-60137 (abgerufen 20.09.2026) – betroffene Versionen 6.8.0–6.9.4 und 7.0.0–7.0.1, behoben in 6.8.6, 6.9.5 und 7.0.2, erzwungene automatische Updates durch Automattic.
• W3Techs: Usage statistics of WordPress (abgerufen 20.09.2026) – 40,2 % aller Websites, 58,8 % aller Websites mit CMS.
• php.net: Supported Versions (abgerufen 20.09.2026) – PHP 8.1 ohne Support seit 31.12.2025, PHP 8.2 Sicherheitsupdates bis 31.12.2026, PHP 8.3 bis 31.12.2027.
• Plugin-Schwachstellen 2026: Elementor Pro CVE-2026-32475 (behoben in 4.2.2, Mitte August 2026), Forminator Forms CVE-2026-15748, WooCommerce Wholesale Lead Capture CVE-2026-27540 (CVSS 9,8) – Herstellerangaben und CVE-Einträge, abgerufen 20.09.2026.

Stand 21. September 2026. Versionsangaben und Support-Daten ändern sich; im Zweifel beim Hersteller nachsehen.