Sicherheitsaudit einer WordPress-Website

#WordPress Sicherheitsaudit: Umfassender Leitfaden 2026

Im Zeitalter der digitalen Transformation ist die Website-Sicherheit keine Option mehr, sondern eine absolute Notwendigkeit. Das Jahr 2025 brachte eine Rekordzahl an Cyberangriffen auf CMS-Systeme, und Prognosen für 2026 deuten auf einen weiteren Anstieg dieses Trends hin, unter anderem getrieben durch die Automatisierung von Angriffen mittels künstlicher Intelligenz (KI). WordPress, das bereits über 43 % aller Websites im Internet betreibt, ist natürlich das Ziel Nummer eins.

Ist Ihre Seite sicher? Sind Sie sicher, dass die Daten Ihrer Kunden nicht geleakt wurden? Ein WordPress Sicherheitsaudit ist nicht nur eine Prüfung, „ob die Seite funktioniert“. Es ist ein komplexer Prozess der Analyse, der Erkennung von Schwachstellen (Vulnerabilities), der Entfernung von Schadsoftwäre (Malware) und der Implementierung von Verteidigungsstrategien wie Hardening.

In diesem Artikel, geschrieben aus der Perspektive eines Entwicklers und Sicherheitsexperten, führe ich Sie durch den kompletten Auditprozess. Sie erfahren, wie Sie Ihr WordPress in der Version 6.7+ sichern, welche Tools Sie im Jahr 2026 verwenden sollten und warum der „Zero Trust“-Ansatz für das Überleben im Netz entscheidend ist.

#Wie Kompromittierungen tatsächlich ablaufen

Die meisten WordPress-Vorfälle, die wir bereinigen, lassen sich auf eine kleine Menge wiederkehrender Muster zurückführen. Diese Muster zu kennen verändert, wonach man im Code und in den Logs sucht.

#Plugins, nicht der Core

Der Core ist seit der 5er-Linie sehr robust gehärtet. Die Einbrüche, die wir sehen, kommen über Plugins, und meistens in denselben Mustern:

• Unauthentifizierte REST-Endpoints, registriert mit permission_callback => '__return_true'. Elementor, WPBakery und mehrere Form Builder haben das im Lauf der Jahre ausgeliefert.
• Stored XSS über Shortcodes, die $_GET oder Post Meta ohne wp_kses_post() ausgeben.
• Beliebiger Datei-Upload über AJAX-Handler, die den Upload akzeptieren, aber wp_check_filetype_and_ext() und die MIME-Whitelist überspringen.
• Privilegieneskalation über update_option('user_role') in einem Settings-Save, der dem Request blind vertraut.

Das Audit gleicht installierte Slugs gegen WPScan und Patchstack ab und liest dann den tatsächlichen Plugin-Quellcode auf die genannten Muster. Reine Datenbankprüfung übersieht Zero-Days, die noch nicht katalogisiert sind.

#REST API und User Enumeration

?author=1 leitet auf /author/<slug>/ weiter und verrät den Admin-Login. 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 Site geben beide 404 oder ein leeres Array zurück.

#XML-RPC-Verstärkung

/xmlrpc.php wird ständig von Loginizer-artigen Botnetzen getroffen. Der Verstärkungstrick auf XML-RPC ist system.multicall, das wp.getUsersBlogs umschließt, sodass ein einziger POST 1000+ Passwörter testen kann. XML-RPC komplett zu deaktivieren funktioniert für 90 % der Sites; wenn Jetpack oder die WordPress-iOS-App im Spiel sind, wird das auf WAF-Ebene eingeschränkt statt entfernt.

#Was Kompromittierung im deutschen Markt konkret bedeutet

Eine kompromittierte Site bedeutet hier praktisch:

1. DSGVO-Meldepflicht nach Art. 33 an die zuständige Landesdatenschutzbehörde innerhalb von 72 Stunden. Der Datenschutzbeauftragte braucht Zugriffslogs, die zeigen, wann unautorisierter Zugriff stattgefunden hat. Eine generische Security-Plugin-Übersicht reicht hier nicht; gefordert ist ein nachvollziehbarer Audit-Trail, idealerweise BSI-Grundschutz-konform abgelegt.
2. ISO 27001 und BSI-Grundschutz-Lücken. Für Mandanten aus FinTech, Gesundheitswesen oder kritischer Infrastruktur ist ein WordPress-Vorfall nicht nur Datenschutz, sondern eine Konformitäts-Lücke gegen den eigenen Maßnahmenkatalog. Wer ISO 27001 zertifiziert ist, muss A.12.6.1 (Verwaltung technischer Schwachstellen) belegen können.
3. Cloudflare-DPA-Konfiguration als KO-Kriterium. Für deutsche Kunden ist nicht egal, dass Cloudflare im Einsatz ist; entscheidend ist die Konfiguration: DPA unterzeichnet, Data Localization auf EU gesetzt, Logpush in eine EU-Region. Ohne diese Einstellungen ist die DSGVO-Konformität schon vor dem Vorfall fragwürdig.
4. SEO-Absturz und Browser-Warnungen. Pharma Hacks und Japanese Keyword Spam führen zu Safe-Browsing-Flags; die Erholung dauert nach dem Cleanup zwei bis sechs Wochen.

#Checkliste für das WordPress Sicherheitsaudit

Ein professionelles Audit ist ein strukturierter Prozess. Die folgende Tabelle zeigt meine proprietäre Checkliste, die ich bei der Arbeit mit Kunden verwende.

#Die häufigsten Infektionsarten (Malware)

Bei Audits begegne ich am häufigsten drei Arten von Bedrohungen:

#1. SEO-Spam (Pharma Hack / Japanese Keywords)

Hacker injizieren Tausende von Seiten mit chinesischen oder japanischen Zeichen, um gefälschte Produkte zu bewerben.

• Symptom: In den Google-Suchergebnissen zeigt Ihre Seite seltsame Zeichen an.
• Folge: Vollständige Sperrung bei Google (Ban) innerhalb von 14 Tagen.

#2. Bösartige Weiterleitungen (Malicious Redirects)

Benutzer, die die Seite betreten, werden auf Glücksspiel- oder Pornoseiten umgeleitet. Dies funktioniert oft nur für mobile Benutzer oder bestimmte Standorte, was die Erkennung erschwert.

• Mechanismus: Geänderte header.php oder infizierte .htaccess-Datei.

#3. PHP-Backdoors

Versteckte Skripte (z. B. in Systemdateien wie wp-includes/images.php), die es dem Hacker ermöglichen, die Kontrolle über die Seite zurückzugewinnen, selbst nachdem Passwörter geändert wurden.

#Hardening, das die Angriffsoberfläche tatsächlich verändert

Hardening ist keine Checkliste, die man einmal abhakt. Es ist ein Satz von Einschränkungen, die die nächste Exploit-Klasse schwerer landbar machen. Diese Änderungen nehmen wir bei jedem Audit vor, ungefähr in dieser Reihenfolge.

wp-config.php-Konstanten. DISALLOW_FILE_EDIT und DISALLOW_FILE_MODS deaktivieren den Code-Editor und den Plugin-Installer im Dashboard. FORCE_SSL_ADMIN blockiert Cookie-Diebstahl in geteilten Netzwerken. WP_AUTO_UPDATE_CORE => 'minor' lässt Sicherheitsreleases durch, ohne an einer Major-Version zu zerbrechen. Die Datei selbst läuft auf 440, gehört dem Deployment-Benutzer, niemals dem Webserver-User. API-Keys (Stripe, SEPA-Provider, Klarna, FinTS) gehören nicht in wp-config.php, sondern in Umgebungsvariablen außerhalb des Web-Roots; andernfalls ist jeder Backdoor in /wp-content/uploads/ ein Schlüssel zum Zahlungssystem.

Secret Rotation. Jedes Audit rotiert die acht Salts (AUTH_KEY, SECURE_AUTH_KEY etc.) über den wordpress.org-Generator und erzwingt das Ausloggen aller Sessions. Wir auditieren außerdem jedes aktive Application Password unter Users → Profile und widerrufen alle, die nicht zu einer dokumentierten Integration gehören.

Login-Layer. Two Factor oder Wordfence Login Security mit TOTP, plus dokumentierter WP-CLI-Fallback-Pfad für den Site-Owner (wp user meta delete <id> _two_factor_* vom Server, falls ein Telefon verloren geht). Login-Throttling am Edge, nicht nur in PHP. Für Cloudflare-Sites: WAF-Custom-Rule, die POSTs auf /wp-login.php auf 5 pro Minute pro IP rate-limited, und ein Managed Challenge auf /xmlrpc.php. Bei Hetzner-WAF (Hetzner Cloud Firewall plus eigene ModSecurity-Rules) lässt sich das Gleiche auf Ebene der Cloud-Firewall lösen; bei deutschen Mandanten oft sauberer, weil der Traffic den EU-Raum nicht verlässt.

Dateisystem. PHP-Ausführung in /wp-content/uploads/ deaktiviert per .htaccess-Regel (<FilesMatch "\.php$"> Require all denied </FilesMatch>) oder dem entsprechenden nginx-Location-Block. wp-config.php eine Ebene über das Web-Root verschoben, wo der Hoster es zulässt. Directory-Listing aus. xmlrpc.php 403, sofern die Site es nicht braucht.

Edge-Filtering. ModSecurity OWASP CRS auf Paranoia 1, mit dokumentierten Site-spezifischen Ausnahmen statt pauschaler Deaktivierung. Custom Rule, die bekannte wp-scan-User-Agents und POSTs an /wp-admin/admin-ajax.php ohne Nonce-Header blockiert. Für ISO-27001-Mandanten gehört der Hardening-Stand in den Maßnahmenkatalog mit Verantwortlichkeit, Review-Datum und nächstem Audit-Termin; sonst hält die Zertifizierungsstelle es nicht für umgesetzt.

Detection, nicht nur Prevention. Täglicher Diff von Core-, Plugin- und Theme-Dateien gegen die Upstream-Zip-Checksumme via WP-CLI (wp checksum core, wp checksum plugin --all). fail2ban beobachtet das Access-Log auf das 200/302-Verhältnis bei /wp-login.php; ein erfolgreicher Brute Force taucht dort eher auf als irgendwo anders. Alerting auf neue Admin-Konten und auf user_register-Events außerhalb der Geschäftszeiten. Für DSGVO-Audit-Trails geht dieser Log in eine separate Prozess mit Aufbewahrung gemäß Verfahrensverzeichnis.

#Drei Vorfallsmuster, die wir immer wieder sehen

Die Zahl „durchschnittliche Kosten eines Vorfalls liegen bei X Euro” ist operativ wertlos. Was zählt, sind die Fehlerklassen, die bei Cleanups regelmäßig auftauchen.

Persistenter Admin-User. Ein verwundbares Formular-Plugin lässt einen Angreifer wp_insert_user() über einen falsch konfigurierten AJAX-Endpoint feuern. Der User bekommt die Rolle administrator und einen unauffälligen Display-Namen wie „Support” oder „Editor”. Das Wiederherstellen des Backups von letzter Woche entfernt ihn nicht, weil die Injection schon davor passiert ist; das Backup ist bereits vergiftet. Wir jagen sie über einen Diff von wp_users und wp_usermeta gegen den letzten sauberen Snapshot, nicht über die Liste im Dashboard. Für DSGVO-Pflichtige ist das relevant; solch ein Konto kann personenbezogene Daten exfiltrieren, ohne dass der reguläre Admin es bemerkt.

Uploads-Backdoor. Eine PHP-Datei abgelegt unter /wp-content/uploads/2024/03/.cache.php nimmt Base64-Payload via POST entgegen und führt eval() darauf aus. Ein partieller Restore, der nur Core und Plugins anfasst, lässt sie am Leben, und der Angreifer ist innerhalb von Stunden zurück. Das Audit tarballt uploads, scannt auf jedes .php, .phtml oder .phar darin und verifiziert, dass das Verzeichnis PHP-Ausführung auf Server-Ebene deaktiviert hat.

Geleakter Schlüssel über öffentliches Repository. Ein Entwickler committet .env mit SMTP-Relay-Credentials und einem Stripe-Restricted-Key in einen öffentlichen GitHub-Mirror. Der Mailer wird innerhalb von 48 Stunden zum Spam-Relay, der Hoster blackholet ausgehenden Port 25, und Stripe sperrt das Konto vorübergehend. Recovery bedeutet Rotation beider Keys, Bereinigung der Git-History via git filter-repo, Pre-Commit-Hooks, die .env-Commits blockieren. Wir prüfen .env, .env.backup, Modifikationen an wp-config-sample.php und jede Datei unter dem Web-Root, die DB_PASSWORD oder _KEY-Muster enthält.

Recovery-Kosten sind hauptsächlich Zeit: Entwicklerstunden zur Identifikation des Eintrittsvektors, Downtime im Maintenance-Mode, SEO-Erholungskurve nach einem Safe-Browsing-Flag (zwei bis sechs Wochen bis zur vollständigen Bereinigung) und das Gespräch mit Kunden, falls personenbezogene Daten betroffen waren. Der Audit-Preis ist klein gegen jeden dieser Einzelposten.

#Was Sie nach dem Sicherheitsaudit erhalten

Das Audit endet mit drei greifbaren Ergebnissen, die innerhalb von fünf Werktagen nach Abschluss der Analyse in Ihrem Postfach landen:

• Technischer Bericht als PDF mit der vollständigen Liste der Befunde, segmentiert nach Priorität (kritisch, hoch, mittel, niedrig). Jeder Eintrag enthält, sofern vorhanden, eine CVE-Referenz, den Angriffsvektor, einen Nachweis in Form eines Screenshots oder Log-Auszugs sowie eine konkrete Behebungsanweisung, die Ihr Entwickler ohne weitere Rückfragen umsetzen kann.
• Security Scorecard im Wertebereich 0-100, aufgeschlüsselt nach fünf Bereichen: Konfigurations-Härtung, Plugin- und Theme-Schwachstellen, Datenbankintegrität, Edge-Exposition (WAF und Edge-Filterung) sowie Angriffserkennung (Logs und Monitoring). So lässt sich der Sicherheitsstand jahresweise vergleichen und der Geschäftsleitung ein messbarer Fortschritt belegen.
• 30-minütiges Video-Walkthrough durch den Bericht, üblicherweise gesehen vom Datenschutzbeauftragten und der technischen Leitung. Wir erklären darin, was wir konkret gefunden haben, in welcher Reihenfolge zu beheben ist und welches Restrisiko akzeptabel bleibt.

Dazu kommt ein 30-tägiger E-Mail-Support während der Umsetzungsphase, in dem wir Rückfragen zu den Patches beantworten. Buchen Sie das Beheben-Paket dazu, setzen wir die kritischen Befunde sofort um und führen anschließend einen Verifikations-Re-Scan durch, der das Schließen jeder gefundenen Lücke bestätigt.

#Was wir von Ihnen benötigen

Das Audit läuft remote, ohne Zutritt zu Ihren Büros oder Geräten. Wir brauchen mindestens drei Dinge, in absteigender Kritikalität:

• Temporärer WordPress-Administrator-Login (Rolle administrator) mit aktivierter Zwei-Faktor-Authentifizierung. Sie legen das Konto für den Audit-Zeitraum an und entfernen es danach. Hosting-Panel-Zugang ist nicht zwingend, wenn wir den WordPress-Admin haben, hilft aber beim tieferen Blick auf die Server-Konfiguration.
• Lesender SSH- oder SFTP-Zugriff auf den Server. Damit prüfen wir die Integrität der Core-Dateien per WP-CLI, kontrollieren Verzeichnisrechte, gehen access.log und error.log durch und decken Backdoors in /wp-content/uploads/ auf. Ohne diesen Zugriff bleibt ein Teil der Angriffsfläche unsichtbar.
• Liste der Integrationen und Schlüssel-Plugins, idealerweise als kurze Textdatei: Name, Version, ob aktiv, und ein Satz zur Funktion. So priorisieren wir die manuelle Code-Prüfung zuerst auf Plugins, die Benutzereingaben annehmen oder REST-Endpoints exponieren.

Optional helfen zusätzlich: Zugang zur Google Search Console (für die schnelle Bestätigung oder den Ausschluss eines Safe-Browsing-Flags), eine Kopie des letzten Audit-Berichts, sowie Zugriff auf das bestehende Monitoring-Tool (Wordfence, Sucuri, Patchstack), damit wir historische Alerts ziehen können. Fehlt etwas davon, schneiden wir den Umfang entsprechend zu und dokumentieren im Bericht, was nicht überprüft werden konnte.

#Wie ein Sicherheitsaudit Ihrem Unternehmen hilft

Ein Audit ist kein technischer Einkauf, sondern das Managen von drei konkreten Geschäftsrisiken:

• Kundenvertrauen und Markenreputation. Eine von Google Safe Browsing markierte oder als Chrome Deceptive Site angezeigte Website verliert innerhalb von Stunden den Zugang zu 60-80 % des organischen Traffics. Die vollständige Sichtbarkeit kehrt nach einem sauberen Cleanup typischerweise erst nach zwei bis sechs Wochen zurück, und bei B2B-Kunden bleibt das verlorene Vertrauen deutlich länger. Ein präventives Audit kostet einen Bruchteil dieser Erholungskurve.
• Regulatorische Konformität. Ein Abfluss personenbezogener Daten aus der WooCommerce-Datenbank oder dem Kontaktformular löst innerhalb von 72 Stunden eine Meldepflicht nach Art. 33 DSGVO an die zuständige Landesdatenschutzbehörde aus, und je nach Umfang die Benachrichtigung der Betroffenen nach Art. 34. Das Audit zeigt, wo Daten liegen, wie sie geschützt sind und ob bei Cloudflare DPA und Data Localization auf EU gesetzt sind. Für Mandanten unter BSI-Mindeststandards bauen wir die Befunde zusätzlich in den Maßnahmenkatalog ein; für Adressaten des NIS2UmsuCG wirken die Inhalte als Grundlage für das Schwachstellenmanagement, und für Cookie-Banner und Tracker prüfen wir die TTDSG-Konformität.
• Finanzielle Verluste. Reale Kosten nach einem Vorfall: 8 bis 40 Entwicklerstunden für die vollständige Reparatur, Downtime des Shops während der Bereinigung, Vertragsstrafen vom Zahlungsdienstleister (Stripe, Klarna, Adyen, lokale Acquirer) wegen Zahlungsdatenverstoß und die juristischen Kosten der Meldung an die Aufsichtsbehörde. Ein präventives Audit schließt die meisten Angriffsvektoren, bevor sie aktiv werden.

Der messbare Geschäftseffekt zeigt sich in drei Kennzahlen: Rückgang der reaktionsbedürftigen Vorfälle um 70-90 % im Jahresvergleich nach vollständigem Hardening, Verkürzung der Mean Time to Detect von Tagen auf Stunden nach Einführung des täglichen Checksumm-Diffs und keine Nutzerbeschwerden mehr über seltsame Weiterleitungen in Google.

Brauchen Sie Unterstützung? Kontaktieren Sie uns für ein scoped Audit, einmalige Bereinigung nach einem Vorfall oder laufendes Monitoring mit monatlichen Checksum-Diffs und vierteljährlichem Re-Audit.