Wer führt das WordPress-Sicherheitsaudit durch?
Ich, Mariusz Szatkowski. Ich entwickle seit 2006 WordPress-Websites und arbeite allein von Gdynia aus. Das Audit mache ich selbst, die Zugänge zu Ihrer Website gebe ich an niemanden weiter. Ein Sicherheitsdienstleister mit Leitstand oder ein Pentest-Unternehmen bin ich nicht.
Was beinhaltet ein WordPress-Sicherheitsaudit?
Das Audit ist eine schriftliche Prüfung Ihrer Website. Es umfasst:
- Plugins und Themes: Versionen, bekannte Schwachstellen, aufgegebene Erweiterungen, Code von Plugins mit Benutzereingaben
- Benutzerkonten, Rollen und Application Passwords
wp-config.php, Dateirechte und die Integrität der Core-Dateien- Server-Header, TLS,
xmlrpc.phpund den öffentlichen Users-Endpoint der REST-API - Backups und den Weg zur Wiederherstellung
- vorhandene Server-Logs, wenn der Hoster sie bereitstellt
- KI-Plugins, die Code ausführen oder auf die Datenbank zugreifen
Das Ergebnis ist ein Bericht mit Befunden nach Priorität und konkreten Behebungsschritten. Ist die Website bereits kompromittiert, folgt die Malware-Entfernung als eigener Auftrag.
Warum ein Audit und nicht nur ein Sicherheits-Plugin
Ein WordPress-Sicherheitsaudit klärt, ob es auf Ihrer Website eine bekannte Lücke, ein fremdes Administratorkonto oder eine abgelegte Hintertür gibt und ob Kundendaten betroffen sein können. Ich gleiche die Plugin-Liste mit bekannten Schwachstellen ab, suche nach Webshells im Dateibaum und prüfe Konfiguration und Zugänge. Ein Sicherheits-Plugin sieht nur, was innerhalb von WordPress passiert. Server-Konfiguration, Dateirechte, Logs und die Frage, wer welchen Zugang hat, bleiben ihm verborgen.
Wie werden WordPress-Seiten gehackt?
Die meisten WordPress-Vorfälle lassen sich auf wenige wiederkehrende Muster zurückführen. Wer sie kennt, weiß, wonach im Code und in den Logs zu suchen ist.
Sicherheitslücken in WordPress-Plugins
Die Einbrüche kommen in der Regel über Plugins, nicht über den Core, und meist nach denselben Mustern:
- Unauthentifizierte REST-Endpoints, registriert mit
permission_callback => '__return_true'. - Stored XSS über Shortcodes, die
$_GEToder Post Meta ohnewp_kses_post()ausgeben. - Beliebiger Datei-Upload über AJAX-Handler, die
wp_check_filetype_and_ext()und die MIME-Prüfung überspringen. - Rechteausweitung über einen Settings-Save, der Rollen aus dem Request ungeprüft übernimmt.
Ich gleiche die installierten Plugins gegen WPScan und Patchstack ab und lese danach den tatsächlichen Quellcode auf diese Muster. Eine reine Datenbankprüfung übersieht Lücken, die noch nicht katalogisiert sind. KI-generierter Code bringt genau diese Fehler häufig mit, fehlende Nonce- und Berechtigungsprüfungen und ungefiltertes $_GET. Wurde Ihre Seite mit einem KI-Tool gebaut, lesen Sie auch die Seite zur Rettung KI-erstellter Websites.
REST API und User Enumeration
?author=1 leitet auf /author/<slug>/ weiter und verrät den Login-Namen. Dasselbe gilt für ?rest_route=/wp/v2/users und /wp-json/wp/v2/users auf Installationen, die den öffentlichen Users-Endpoint nie eingeschränkt haben. Auf einer gehärteten Website liefern beide 404 oder eine leere Liste.
XML-RPC-Angriffe mit system.multicall
/xmlrpc.php wird laufend von Botnetzen abgefragt. Über system.multicall, das viele wp.getUsersBlogs-Aufrufe bündelt, testet eine einzige Anfrage eine ganze Reihe von Passwörtern. Die meisten Websites brauchen XML-RPC nicht und können es abschalten. Nutzen Jetpack oder die WordPress-App es, schränke ich den Zugriff am Server oder am CDN ein, statt es zu entfernen.
Folgen eines WordPress-Hacks für Unternehmen
- Meldepflicht nach Art. 33 DSGVO. Sind personenbezogene Daten betroffen, meldet der Verantwortliche die Verletzung unverzüglich und möglichst binnen 72 Stunden der zuständigen Aufsichtsbehörde, es sei denn, sie führt voraussichtlich nicht zu einem Risiko für die Betroffenen. Verantwortlicher sind Sie, nicht der Dienstleister. Dafür brauchen Sie Zugriffslogs, die zeigen, wann jemand unberechtigt zugreifen konnte.
- Konfiguration des CDN. Läuft die Website über Cloudflare oder ein anderes CDN, prüfe ich, ob ein Auftragsverarbeitungsvertrag geschlossen ist und wo Logs gespeichert werden.
- Sichtbarkeit in Google. Pharma-Hacks und japanischer Keyword-Spam führen zu Warnungen in Google Safe Browsing und in den Suchergebnissen. Die Warnung verschwindet erst nach Bereinigung und Überprüfungsantrag in der Search Console.
Checkliste für das WordPress-Sicherheitsaudit
| Schritt | Tätigkeit | Werkzeuge |
|---|---|---|
| 1. Externer Scan | Sichtbare Infektionen, Prüfung von Sperrlisten (Google Safe Browsing), Server-Header | WPScan, Sucuri SiteCheck |
| 2. Core-Dateien | Vergleich mit den offiziellen Prüfsummen, Suche nach Hintertüren | WP-CLI, Wordfence |
| 3. Plugins und Themes | Aufgegebene Erweiterungen und bekannte Lücken (CVE) | WPScan, Patchstack |
| 4. Datenbank | Eingeschleuster Code, Spam-Links, unbekannte Administratoren | SQL-Abfragen, WP-CLI |
| 5. Server-Logs | access.log und error.log auf Einbruchsspuren | SSH, grep, awk |
Häufigste Malware-Infektionen bei WordPress
1. Pharma-Hack und japanischer SEO-Spam
Angreifer legen Tausende Seiten mit Werbung für gefälschte Produkte an, oft in japanischer oder chinesischer Schrift. Sie sehen es in den Suchergebnissen: Unter Ihrer Domain stehen Titel, die Sie nie veröffentlicht haben.
2. Bösartige Weiterleitungen
Besucher landen auf Glücksspiel- oder Pornoseiten. Oft trifft es nur Smartphones oder bestimmte Länder, was die Entdeckung erschwert. Der Mechanismus steckt meist in einer geänderten header.php oder einer infizierten .htaccess.
3. PHP-Hintertüren
Versteckte Skripte, etwa unter einem unauffälligen Namen in wp-includes/, geben dem Angreifer die Kontrolle zurück, auch nachdem alle Passwörter geändert wurden.
Sicherheitsaudit für mit KI erstellte WordPress-Seiten
Websites, die mit KI-Tools gebaut oder stark erweitert wurden, scheitern im Audit an vorhersehbaren Stellen: fehlende Nonces, ungefilterte Eingaben, offene REST-Routen und viele Plugins aus wiederholten Prompts.
| Ebene | Prüfung | Typischer Fund |
|---|---|---|
| Code | Eigene Plugins, functions.php des Themes | Fehlende Capability-Checks, zusammengesetzte SQL-Strings |
| Oberfläche | REST, AJAX, Uploads | permission_callback => '__return_true' |
| Inhalt | Duplikate, erfundene Statistiken | Texte mit Risiko für Gesundheits- oder Finanzthemen |
Die Behebung beschreibe ich unter Rettung KI-erstellter Websites, Code-Muster unter Audit KI-generierter Plugin-Code und Inhalte unter AI-Slop-Bereinigung.
Sind KI-Plugins mit Code-Ausführung sicher?
Es gibt Plugins, die einem KI-Agenten absichtlich PHP-Ausführung, Datenbankabfragen und Dateioperationen geben, über MCP, CLI oder Webhook. Das ist eine dokumentierte Funktion, die im Ergebnis einer Codeausführung durch eine externe Partei entspricht. Ein CVE-Scanner meldet dabei nichts, weil kein Fehler vorliegt. Das Risiko liegt bei Authentifizierung und Lieferkette: Wer den Schlüssel zum Endpoint hat, wo das Secret liegt, ob der Endpoint aus dem Internet erreichbar ist und was passiert, wenn das Konto beim Modellanbieter übernommen wird.
Jedes Audit enthält deshalb fünf zusätzliche Punkte:
- Inventar der Plugins, die KI-gesteuerte Codeausführung, Datenbankzugriff oder Dateioperationen anbieten.
- Pro Plugin: ob der Endpoint Authentifizierung verlangt und ob er öffentlich erreichbar ist.
- Wo Zugangsdaten liegen (
wp-config.php, Options-Tabelle, Umgebungsvariablen) und wer sie lesen kann. - Ob ausgeführte Operationen so protokolliert werden, dass man sie nach einem Vorfall nachvollziehen kann.
- Meine Standardempfehlung: nicht in Produktion, auf Staging nur mit Zustimmung und IP-Freigabeliste.
WordPress-Hardening Schritt für Schritt
Diese Maßnahmen empfehle ich im Bericht, je nach Befund in dieser Reihenfolge. Die Umsetzung übernehme ich auf Wunsch.
Konstanten in wp-config.php. DISALLOW_FILE_EDIT und DISALLOW_FILE_MODS schalten Code-Editor und Plugin-Installation im Dashboard ab. FORCE_SSL_ADMIN erzwingt HTTPS für die Anmeldung. Die Datei selbst bekommt restriktive Rechte und gehört dem Deployment-Benutzer, nicht dem Webserver. API-Schlüssel für Zahlungsanbieter wie Stripe oder Klarna gehören in Umgebungsvariablen außerhalb des Web-Roots; sonst wird jede Hintertür in /wp-content/uploads/ zum Schlüssel für das Zahlungssystem.
Schlüssel erneuern. Die acht Salts (AUTH_KEY, SECURE_AUTH_KEY usw.) werden neu erzeugt, damit alle Sitzungen enden. Jedes aktive Application Password, das zu keiner dokumentierten Integration gehört, wird widerrufen.
Anmeldung. Zwei-Faktor-Anmeldung mit TOTP über das Plugin Two Factor oder Wordfence Login Security, dazu ein dokumentierter Rückweg per WP-CLI, falls ein Telefon verloren geht. Anmeldeversuche begrenze ich vor PHP: bei Cloudflare über eine Rate-Limiting-Regel für POST-Anfragen auf /wp-login.php und eine Managed Challenge auf /xmlrpc.php, auf einem eigenen Server über nginx oder ModSecurity.
Dateisystem. PHP-Ausführung in /wp-content/uploads/ wird per .htaccess oder nginx-Location-Block gesperrt. wp-config.php liegt eine Ebene über dem Web-Root, wo der Hoster es zulässt. Verzeichnislisten sind aus, xmlrpc.php liefert 403, sofern es nicht gebraucht wird.
Filter am Rand. ModSecurity mit OWASP Core Rule Set auf Paranoia-Level 1, mit dokumentierten Ausnahmen pro Website statt pauschaler Abschaltung.
Erkennen statt nur verhindern. Regelmäßiger Abgleich von Core-, Plugin- und Theme-Dateien mit den offiziellen Prüfsummen per WP-CLI (wp core verify-checksums, wp plugin verify-checksums --all). fail2ban beobachtet das Verhältnis erfolgreicher und fehlgeschlagener Anmeldungen an /wp-login.php. Neue Administratorkonten lösen eine Benachrichtigung aus.
Häufige Fehlerklassen nach einem WordPress-Hack
Verstecktes Administratorkonto. Ein verwundbares Formular-Plugin erlaubt das Anlegen eines Benutzers mit der Rolle administrator und einem unauffälligen Namen wie „Support“. Ein Backup von letzter Woche entfernt ihn nicht, wenn das Konto schon davor angelegt wurde. Ich suche solche Konten über einen Vergleich von wp_users und wp_usermeta mit dem letzten sauberen Stand, nicht über die Liste im Dashboard.
Hintertür in den Uploads. Eine PHP-Datei unter /wp-content/uploads/ nimmt Base64-Daten per POST entgegen und führt sie mit eval() aus. Eine Wiederherstellung, die nur Core und Plugins erneuert, lässt sie bestehen. Ich prüfe das Verzeichnis auf jede .php-, .phtml- oder .phar-Datei und kontrolliere, ob PHP-Ausführung dort auf Server-Ebene gesperrt ist.
Zugangsdaten in einem öffentlichen Repository. Eine .env mit SMTP-Zugang oder Zahlungs-API-Schlüssel landet in einem öffentlichen Git-Repository. Die Folge reicht vom Spam-Versand über den eigenen Mailserver bis zu gesperrten Konten beim Zahlungsanbieter. Die Behebung heißt: Schlüssel erneuern, Git-History bereinigen, Pre-Commit-Hooks einrichten. Im Audit suche ich unter dem Web-Root nach .env-Dateien, Sicherungskopien von wp-config.php und jeder Datei mit DB_PASSWORD oder Schlüsselmustern.
Was enthält der Bericht zum Sicherheitsaudit?
Sie erhalten einen schriftlichen Bericht als PDF mit allen Befunden, sortiert nach Priorität: kritisch, hoch, mittel, niedrig. Jeder Eintrag nennt, sofern vorhanden, die CVE-Nummer, den möglichen Angriffsweg, einen Nachweis als Screenshot oder Log-Auszug und eine konkrete Behebungsanweisung, die auch ein anderer Entwickler umsetzen kann. Was ich mangels Zugang nicht prüfen konnte, steht ausdrücklich im Bericht.
Rückfragen zum Bericht beantworte ich per E-Mail. Die Umsetzung der Maßnahmen ist ein eigener Auftrag; danach prüfe ich erneut, ob die Befunde geschlossen sind.
Website gehackt: was in der ersten Stunde zu tun ist
- Nichts löschen. Dateien und Datenbank im jetzigen Zustand sichern. Infizierte Dateien zeigen den Einstiegspunkt.
- Passwörter von einem sauberen Gerät ändern: WordPress-Admin, Hosting, SFTP, Datenbank, API-Schlüssel für Zahlung und Mail. Alle Sitzungen abmelden.
- Seite offline nehmen oder Wartungsmodus aktivieren, wenn sie Malware ausliefert, Besucher umleitet oder Formular- und Zahlungsdaten abgreift.
- Beim Hoster
access.logunderror.loganfordern und fragen, wie lange sie aufbewahrt werden. Ohne Logs lässt sich nicht klären, was gelesen wurde. - Google Search Console prüfen. Ein fremder Inhaber ist ein häufiges Zeichen eines Einbruchs; entfernen Sie ihn erst nach der Sicherung.
- Uhrzeit der Feststellung notieren. Ab diesem Zeitpunkt läuft die 72-Stunden-Frist nach Art. 33 DSGVO.
Wie läuft eine Bereinigung nach dem Hack ab?
Ich arbeite an einer Kopie, nicht an der Live-Seite. Zuerst kommt der Einstiegsweg (Logs, wp core verify-checksums, Vergleich der Plugin- und Theme-Dateien), dann das Entfernen von Malware und Hintertüren in Dateien und Datenbank, die Prüfung von Administratorkonten und Cronjobs, der Neuaufbau von Core und Plugins aus sauberen Quellen und der Austausch aller Zugangsdaten. Am Ende stehen ein Prüfscan und, falls Google die Seite markiert hat, ein Überprüfungsantrag. Die Dauer hängt von der Zahl infizierter Dateien und vom Vorhandensein von Logs ab; eine Schätzung gebe ich erst nach Sichtung der Seite.
Muss man nach einem Hack einen Datenabfluss melden?
Die Entscheidung liegt bei Ihnen als Verantwortlichem und bei Ihrem Datenschutzbeauftragten, falls Sie einen haben. Art. 33 Abs. 1 DSGVO verlangt die Meldung an die zuständige Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden, nachdem Ihnen die Verletzung bekannt wurde, es sei denn, sie führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten der Betroffenen. Bei voraussichtlich hohem Risiko verlangt Art. 34 Abs. 1 zusätzlich die Benachrichtigung der Betroffenen. Jede Verletzung, auch eine nicht gemeldete, ist nach Art. 33 Abs. 5 zu dokumentieren.
Zuständig sind in Deutschland für Unternehmen die Datenschutzbehörden der Länder (§ 40 BDSG), in Österreich die Datenschutzbehörde (§ 18 DSG). Von mir bekommen Sie, was Ihre Rechtsberatung braucht: ob personenbezogene Daten in der Datenbank lagen, ob jemand darauf zugreifen konnte und seit wann.
Quellen: DSGVO auf EUR-Lex, EDSA-Leitlinien 9/2022 zur Meldung von Datenpannen, § 40 BDSG, Datenschutzgesetz im RIS.
Was folgt nach der Bereinigung?
Das Hardening aus dem Abschnitt oben: Zwei-Faktor-Anmeldung, abgeschalteter Dateieditor, regelmäßiger Prüfsummenabgleich und Filterung am Rand. Ohne das bleibt derselbe Einstieg offen.
Welche Zugänge braucht ein WordPress-Sicherheitsaudit?
Das Audit läuft remote. Bevor ich Zugang bekomme, schließen wir einen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO. Ich brauche:
- Ein eigenes WordPress-Administratorkonto mit Zwei-Faktor-Anmeldung, das Sie für den Zeitraum des Audits anlegen und danach löschen.
- Lesenden SSH- oder SFTP-Zugriff. Damit prüfe ich die Core-Dateien per WP-CLI, die Verzeichnisrechte, die Logs und das Uploads-Verzeichnis. Ohne diesen Zugriff bleibt ein Teil der Angriffsfläche unsichtbar.
- Eine kurze Liste der Integrationen: welche Plugins Daten an Dritte senden oder Eingaben annehmen. So beginne ich die Code-Prüfung dort, wo das Risiko am größten ist.
Zugang zur Google Search Console und zu einem bestehenden Sicherheits-Plugin (Wordfence, Sucuri, Patchstack) hilft zusätzlich. Fehlt etwas davon, steht im Bericht, was deshalb nicht geprüft wurde.
Anfrage
Beschreiben Sie über das Kontaktformular Ihre Website, den Hoster und den Anlass: Verdacht auf einen Vorfall, Übernahme einer fremden Website oder eine Prüfung vor dem Start. Sie bekommen schriftlich Rückfragen oder ein Angebot. Damit die Härtung bei wechselnden Plugins erhalten bleibt, gibt es danach die laufende WordPress-Wartung.
Vorab können Sie selbst nachsehen: Der WordPress-Website-Check ruft die öffentliche Fassung einer Adresse ab und zeigt Statuscode, Header und die Anfragen, die den ersten Bildaufbau blockieren.
