WordPress Sicherheitsaudit - individuelles Angebot

#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 Compliance-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 Pipeline 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.

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.