WordPress Sicherheitslücken finden, schließen & vorbeugen

WordPress ist das meistgenutzte CMS der Welt und damit das primäre Ziel automatisierter Bot-Netzwerke. Angriffe erfolgen heute selten gezielt und manuell, sondern durch Skripte, die das Netz permanent nach bekannten Schwachstellen scannen.

Laut dem aktuellen WordPress Security Report von Patchstack entstanden 91 % aller neu entdeckten Sicherheitslücken durch Plugins und 9 % durch Themes. Im Core von WordPress wurden im selben Zeitraum lediglich 6 Schwachstellen registriert, die allesamt als geringfügig („low priority“) eingestuft wurden.

Sicherheits-Plugins wie Wordfence oder WP Cerber können gegen Angriffe helfen, sollten aber nicht die einzige Maßnahme sein. Nachhaltige Sicherheit erfordert Hardening auf Serverebene und in der Kernkonfiguration.

In diesem Praxis-Guide lernst du, was die technischen Ursachen für WordPress-Hacks sind, wie Lücken manuell ohne zusätzliche Plugins geschlossen werden und was du tun solltest, falls deine Website schon gehackt wurde.

Das Wichtigste in Kürze

So schützt du deine Website vor Angriffen:

• Updates & vPatching: WP-Core, PHP (8.2+) und Erweiterungen aktuell halten. Bei komplexen Page Buildern und kritischen Plugin-Lücken auf automatisches vPatching bzw. serverseitige Schutz-Tools (wie Patchman) setzen.
• Zugang & Rollen: Standard-Nutzer admin löschen, 2FA erzwingen und Nutzerrechte nach dem Least-Privilege-Prinzip strikt begrenzen.
• Dateisystem & Uploads: Korrekte CHMOD-Rechte setzen (keine 777) und die Ausführung von PHP-Skripten im Ordner /wp-content/uploads/ via .htaccess blockieren.
• Schnittstellen: Die veraltete xmlrpc.php blockieren und sensible REST-API-Endpunkte sperren, um Brute-Force-Attacken und Broken Access Control abzuwehren.
• Infrastruktur: Auf isolierte Container-Umgebungen setzen (statt Shared Hosting) und serverseitige Firewalls nutzen, statt die Datenbank mit schweren Security-Plugins zu belasten.
• Backups: Automatisierte, isolierte Backups nutzen, die physisch getrennt vom eigentlichen Webspace gespeichert werden.

---

Wie erkenne ich Sicherheitslücken auf meiner Website?

Die meisten Hacks nutzen eine der folgenden drei Methoden:

• Cross-Site Scripting (XSS): Bösartige Skripte (meist JavaScript) werden über ungeschützte Eingabefelder eingeschleust und im Browser der Website-Besucher ausgeführt.
• SQL-Injektion (SQLi): Schadcode wird direkt an die Datenbank gesendet, um Daten abzugreifen oder Admin-Rechte zu manipulieren.
• Cross-Site Request Forgery (CSRF): Ein eingeloggter Administrator wird im Hintergrund (z. B. durch einen präparierten Link) dazu gebracht, ungewollte Aktionen auszuführen.

Gefundene vs. tatsächlich ausgenutzte Lücken

Nicht jede Sicherheitslücke wird auch direkt ausgenutzt. Die Zahlen der gefundenen und der tatsächlich genutzten Lücken gehen teilweise stark auseinander:

• Am häufigsten im Code zu finden: Cross-Site Scripting (XSS) macht in Datenbanken regelmäßig rund 50 % aller gemeldeten Plugin-Lücken aus, da sich fehlendes Escaping durch automatisierte Code-Scans leicht aufspüren lässt.
• Was Hacker auf Live-Websites am häufigsten angreifen: Im Patchstack Security Report dominieren bei den von Firewalls abgefangenen Angriffen Broken Access Control (57 %) (unzureichende Prüfung von Nutzerrechten) und Privilege Escalation (20 %) (eigenmächtige Erweiterung der eigenen Nutzerrechte). Bei beiden Varianten können Angreifer ohne Interaktion des Website-Betreibers eintreten, was sie besonders gefährlich macht.

Was ist eine Zero-Day-Sicherheitslücke (Zero-Day Exploit)?

Von einer Zero-Day-Lücke spricht man, wenn eine Schwachstelle entdeckt und bereits aktiv ausgenutzt wird, bevor der Entwickler davon erfährt oder einen Patch bereitstellen konnte. Der Entwickler hat ab dem Bekanntwerden genau „null Tage“ Zeit für eine Reaktion. Gegen solche Lücken helfen herkömmliche signaturbasierte Scanner nicht – hier schützen primär serverseitige Web Application Firewalls (WAF), die auffälliges Anfrageverhalten stoppen.

Die ersten Schritte zu mehr Sicherheit

Bevor du Konfigurationsdateien anpasst, solltest du dein System auditieren:

• Dashboards & Update-Hinweise prüfen: WordPress zeigt veraltete Plugins im Backend an. Ein Blick in die Changelogs verrät, ob ein Update wichtige Security Fixes enthält.
• Sicherheits-Datensätze abgleichen: Datenbanken wie die WPScan Vulnerability Database, WPVulnerability API oder Patchstack erlauben das gezielte Durchsuchen installierter Plugins nach bekannten Lücken.
• Automatisierte Scanner nutzen: Werkzeuge wie Sucuri SiteCheck (sitecheck.sucuri.net) oder der Google Safe Browsing Status scannen die Seite von außen auf Malware und veraltete Komponenten.
• Verwaiste Plugins filtern: Wurde ein Plugin seit über 12 Monaten nicht mehr gepflegt oder aus dem offiziellen Directory entfernt, sollte es umgehend ersetzt werden.

---

Die 5 häufigsten Sicherheitslücken & wie du sie schließt

1. Veraltete & verwaiste Plugins, Themes & Core-Dateien

Mit 90% aller Sicherheitslücken liegt das mit Abstand größte Risiko in veralteten Plugin- und Theme-Dateien. Laut Patchstack erfordern über 50 % aller Plugin-Sicherheitslücken keinerlei Anmeldung (unauthenticated). Angreifer müssen sich nicht einmal einloggen, um den Schadcode auszuführen. Neben verzögerten Updates sind verwaiste Plugins (seit mehr als 12 Monaten nicht mehr gepflegt) das Hauptrisiko.

Bei Raidboxes haben wir die gleiche Erfahrung gemacht. Die meisten Support-Anfragen bezüglich Malware hängen zusammen mit veralteten Plugins, die irgendwann installiert und dann vergessen wurden oder zwar deaktiviert, aber nicht gelöscht wurden. Besonders Page Builder wie Elementor oder Divi tauchen in unseren Support-Tickets immer wieder auf. Der komplexe Code und der Einsatz verschiedener Schnittstellen gepaart mit der großen Verbreitung machen sie zu einem beliebten Einfallstor für Hacker. Die Masse an Drittanbieter-Add-ons verstärkt das Problem zusätzlich.

Die Sicherheitslücken in Plugins betreffen nicht nur die vielen kostenlosen Plugins, die es für WordPress gibt. Laut Patchstack wurden 29% der Sicherheitslücken in kostenpflichtigen Premium- oder Freemium-Versionen gefunden. Über die Hälfte (59%) davon werden als sehr gefährlich eingestuft.

Wie kann ich mich davor schützen?

• Update-Routine automatisieren: Aktiviere automatische Updates für Minor-Releases von Core und Plugins. Teste Major-Updates vorab in einer Staging-Umgebung.
• Unnötiges löschen: Deaktiviere nicht genutzte Plugins nicht nur, sondern lösche sie vollständig vom Server.
• vPatching nutzen: Werkzeuge wie Patchstack einsetzen, um Lücken virtuell abzudichten, bevor ein offizielles Entwickler-Update vorliegt.
• Backend-Editor deaktivieren: Unter Design > Theme-Datei-Editor können Dateien direkt im Dashboard bearbeitet werden. Gelingt einem Angreifer der Login, nutzt er diesen Editor häufig für Backdoors. Füge folgenden Code in deine wp-config.php (vor der Zeile /* That’s all, stop editing! Happy publishing. */) ein:

define( 'DISALLOW_FILE_EDIT', true );

• WordPress-Versionsnummer verbergen: Standardmäßig gibt WordPress seine Version im Quelltext aus. Bots suchen gezielt nach veralteten Nummern. Füge diesen Code in die functions.php deines (Child-)Themes ein:

remove_action('wp_head', 'wp_generator');

2. Schwache Zugangsdaten & fehlende 2FA

Menschliches Fehlverhalten ist der zweite große Risikofaktor. Die Nutzung des Standard-Benutzernamens admin, leicht zu erratende Passwörter und das Fehlen einer Zwei-Faktor-Authentifizierung (2FA) erleichtern die Übernahme von Accounts massiv. Ein weiteres Risiko sind verwaiste Administrator-Konten von ehemaligen Dienstleistern oder Mitarbeitern.

Wie kann ich mich davor schützen?

• Standard-Admin & User-ID 1 ersetzen: Lautet dein Admin-Nutzername noch admin, lege einen neuen Administrator mit individuellem Namen an, logge dich mit diesem ein und lösche den alten admin-Account. Weise bestehende Beiträge beim Löschen dem neuen Account zu.
• Zwei-Faktor-Authentifizierung (2FA) erzwingen: Falls dein Hoster keine serverseitige 2FA anbietet, richte über ein schlankes Plugin (z. B. Two Factor oder WP 2FA) eine Pflicht zur 2FA für alle Konten ab der Rolle „Redakteur“ ein.
• Least-Privilege-Prinzip (Rollen trennen): Vergib Administrator-Rechte nur an Personen, die technische Änderungen vornehmen müssen. Redakteure, SEO-Manager oder Gastautoren erhalten strikt nur die Rechte, die sie für ihre Rolle benötigen.
• Passwort-Manager nutzen: Nutze kryptische Passwörter mit mindestens 16 Zeichen.

Es mag simpel klingen, aber bei Raidboxes haben wir die Erfahrung gemacht, dass schwache Passwörter, eine fehlende 2-Faktor-Authentifizierung und ein unsauberes Usermanagement neben veralteten Plugins die mit Abstand häufigste Ursache für Malware und Hackerangriffe sind. Gleichzeitig ist es aber auch eine der Sicherheitslücken, die am einfachsten zu schließen ist – ohne großes technisches Wissen.

3. Offene Schnittstellen & Brute-Force-Attacken

Automatisierte Skripte testen tausende Login-Kombinationen pro Minute. Dies geschieht über die reguläre Login-Seite (wp-login.php) oder die veraltete xmlrpc.php-Schnittstelle. Ungeschützt dient XML-RPC Bot-Netzwerken als primäre Angriffsfläche für Brute-Force- und DDoS-Attacken.

Wie kann ich mich davor schützen?

• Die xmlrpc.php-Schnittstelle sperren: Sofern keine spezifischen Dienste genutzt werden, die zwingend auf XML-RPC angewiesen sind, sollte die Datei blockiert werden. Bei Raidboxes haben wir uns aus Sicherheitsgründen dazu entschieden, die xmlrpc.php für externe Zugriffe standardmäßig zu blockieren. Kunden können sie im Einzelfall über das Dashboard wieder freischalten, wenn eine bestimmte Integration dies zwingend erfordert. Um die xmlrpc.php zu blockieren, füge diesen Code in deine .htaccess ein:

# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>

• Anmeldungen limitieren: Beschränke fehlerhafte Login-Versuche pro IP-Adresse (z. B. via Limit Login Attempts Reloaded oder serverseitiger Firewall).
• Datenbank-Präfix ändern: Automatisierte SQL-Injektionen zielen häufig auf die Standard-Tabellennamen ab (wp_xxx). Ändere das Präfix deiner Datenbank-Tabellen über dein Hosting-Interface oder phpMyAdmin. Dies erfordert einen direkten Eingriff in die Datenbank und sollte nicht von Laien durchgeführt werden.
•  WP-Salts erneuern: Die Sicherheitsschlüssel (Salts) in der wp-config.php verschlüsseln die Passwörter in den Cookies. Werden diese Schlüssel ausgetauscht, werden alle aktuell eingeloggten Benutzer sofort abgemeldet. Neue Salts können über den offiziellen WordPress Secret-Key Generator erzeugt und in die wp-config.php kopiert werden.

4. Unsichere Dateirechte & ungeschützte Uploads

Dateirechte (CHMOD) definieren auf Serverebene, wer Dateien lesen, schreiben oder ausführen darf. Zu weit gefasste Zugriffsrechte erlauben es externen Skripten, Systemdateien direkt zu überschreiben. Zudem laden Angreifer häufig bösartige PHP-Skripte getarnt als Bilder in den Uploads-Ordner hoch.

Gelingt es Angreifern, über eine Plugin-Lücke eine Datei hochzuladen, platzieren sie häufig sogenannte Web-Shells (wie wp2shell). Diese PHP-Skripte dienen als dauerhafte Hintertür (Backdoor), über die Hacker Befehle direkt auf dem Server ausführen, Datenbanken auslesen oder weiteren Schadcode nachladen können. Die Blockade von PHP-Dateien im Uploads-Verzeichnis nimmt solchen Skripten sofort die Grundlage.

Wie kann ich mich davor schützen?

• Verzeichnis-Browsing blockieren: Verhindere, dass Besucher die komplette Ordnerstruktur einsehen können. Füge diese Zeile unten in deine .htaccess im Hauptverzeichnis ein:

Options -Indexes

• HTTPS/SSL erzwingen: Binde ein SSL-Zertifikat ein und richte eine serverseitige 301-Weiterleitung von HTTP auf HTTPS ein.
• PHP-Ausführung im Uploads-Ordner stoppen: Erstelle eine neue .htaccess-Datei mit folgendem Inhalt und lade sie per (S)FTP ausschließlich in den Ordner /wp-content/uploads/ hoch:

<Files *.php>
deny from all
</Files>

• Dateirechte (CHMOD) korrekt setzen: Falsche Dateirechte machen es Angreifern leicht, Systemdateien zu überschreiben. CHMOD-Werte werden mit einer Kombination aus 3 Ziffern dargestellt (z. B. 755). Die Ziffern stehen für den Besitzer, die Benutzergruppe und alle anderen Nutzer im Internet:
  • 0: Keine Rechte
  • 1: Darf ausführen
  • 2: Darf schreiben
  • 4: Darf lesen
  • 5: Darf lesen und ausführen (4 + 1)
  • 6: Darf lesen und schreiben (4 + 2)
  • 7: Darf lesen, schreiben und ausführen (4 + 2 + 1 = volle Rechte)

• Prüfe über dein FTP-Programm die CHMOD-Rechte. Für WordPress gelten folgende Standard-Empfehlungen:
  • Ordner (Verzeichnisse): 755
  • Dateien: 644
  • wp-config.php: 400 oder 440 (schützt sensible Zugangsdaten maximal vor Lesezugriffen anderer Server-Nutzer).
  • Niemals darf ein Ordner oder eine Datei den Wert 777 (Vollzugriff für alle) haben.

5. Veraltete PHP-Versionen & unsicheres Shared Hosting

Der Server selbst stellt eine fundamentale Schwachstelle dar. Veraltete PHP-Versionen (End-of-Life) erhalten keine Sicherheitspatches mehr. Auf klassischen Shared-Hosting-Servern teilen sich zudem hunderte Kunden dieselbe Systemumgebung. Fehlt eine Container-Isolierung, kann sich Malware von gehackten Nachbar-Websites ausbreiten (Bad-Neighbor-Effekt).

Wie kann ich mich davor schützen?

• PHP-Upgrades durchführen: Nutze ausschließlich vom PHP-Projekt offiziell unterstützte PHP-Versionen und führe regelmäßige Versions-Upgrades im Hoster-Dashboard durch.
• Isolierte Container-Infrastruktur wählen: Setze auf Managed WordPress Hosting mit dedizierten, isolierten Server-Containern (z. B. Docker/LXC-Umgebungen) anstelle von klassischem Shared Hosting.
• Serverseitige WAF nutzen: Setze auf Hoster mit integrierter Exploit-Protection auf Nginx/Apache-Ebene, die Angriffsmuster filtert, bevor sie WordPress erreichen.

Raidboxes-Kommentar: Durch einen Shared Hosting Anbieter hat sich in einer meiner früheren WordPress Seiten Malware installiert, welche sich automatisch verbreitet hat und verschlüsselte .php-Dateien in bekannte Ordner platziert hat. Diese hat damals die komplette Webseite lahm gelegt (wp relevanten Ordner gelöscht) und es hat Tage gedauert, alle infizierten Dateien zu beseitigen. – Sahin Habermann, Web Dev, Raidboxes

---

Frühwarnsysteme, Security-Plugins & serverseitige Tools

Eine nachhaltige Sicherheitsstrategie kombiniert proaktive Überwachung, Anwendungs-Hardening und serverseitige Schutzmechanismen.

• WPScan / WPVulnerability API / Patchstack: Diese Dienste betreiben globale Datenbanken zur kontinuierlichen Überwachung installierter Komponenten. Über automatisierte E-Mail-Alerts wirst du sofort benachrichtigt, sobald für eine deiner genutzten Plugin- oder Theme-Versionen eine Schwachstelle registriert wird.
• Patchman (Serverseitiges Vulnerability-Monitoring): Scannt das Dateisystem auf Serverebene automatisch nach veralteten, verwundbaren Software-Dateien und schlägt Alarm (bzw. schließt die Lücke automatisch), bevor der Code ausgenutzt werden kann.
• Sucuri SiteCheck (sitecheck.sucuri.net): Ein kostenloser externer Scanner, der eine URL von außen auf bekannten Schadcode, veraltete Server-Komponenten, Webserver-Fehlkonfigurationen und Einträge auf Web-Blacklists prüft.
• Google Safe Browsing Status: Prüft den offiziellen Sicherheitsstatus einer Domain aus Sicht der Google-Crawler, um einer drohenden Deindexierung frühzeitig vorzubeugen.

Können Security-Addons helfen? 

Die Installation umfangreicher Security-Suites direkt nach dem Aufsetzen einer WordPress-Instanz ist weit verbreitet, bringt jedoch herstellungsbedingte Nachteile auf Applikationsebene mit sich:

• Performance-Verlust: Da Plugins Zugriffe in Echtzeit über die PHP-Engine verarbeiten, verbraucht jeder Aufruf Server-Ressourcen und verschlechtert die Ladezeit (Time-To-First-Byte / TTFB).
• Datenbank-Wachstum: Umfangreiche Protokollierungen für Fehl-Logins, 404-Fehler und IP-Scans blähen die MySQL-Datenbank langfristig stark auf.
• Eigene Sicherheitslücken: Durch ihren immensen Funktionsumfang und tiefen Systemzugriff wiesen komplexe Security-Plugins in der Vergangenheit selbst mehrfach kritische Schwachstellen auf.

Sicherheits-Lösungen im Detail

Sicherheits-Tools können auf Applikationsebene (Plugins) und Serverebene (Hosting-Infrastruktur) arbeiten.

1. Wordfence Security (Klassisches Plugin)

Wordfence kombiniert eine Endpoint-Firewall auf PHP-Ebene mit einem lokalen Signatur-Scanner.

• Extended Protection Mode: In dieser Konfiguration nutzt Wordfence die PHP-Anweisung auto_prepend_file in der .user.ini oder php.ini. Dadurch startet das Wordfence-Skript noch bevor die wp-config.php und der restliche WordPress-Core geladen werden. Das fängt Anfragen früher ab als Standard-Plugins, verbraucht aber bei jedem einzelnen Request PHP-Arbeitsspeicher des Servers.
• Malware-Scanner (Signature & Hash Matching): Vergleicht den MD5-Hash aller Core- und Repository-Dateien mit der offiziellen WordPress.org-Datenbank und durchsucht den Quellcode mittels regulärer Ausdrücke (Regex) nach bösartigen Mustern wie eval(base64_decode(…)).
• Nachteile: Das Feature Live Traffic protokolliert jeden einzelnen HTTP-Aufruf direkt in der MySQL-Datenbank (wp_wfls_2fa_secrets, wp_wfhits etc.). Bei Seiten ab 50.000 Aufrufen/Monat kann dies die Datenbank extrem aufblähen und sperren. In der kostenlosen Version werden neue Firewall-Regeln und Malware-Signaturen erst mit 30 Tagen Verzögerung eingespielt.

2. Patchman (Serverseitige Anwendung – Kein Plugin)

Bei Raidboxes nutzen wir Patchman. Das Tool unterscheidet sich grundlegend von WordPress-Plugins, da es als eigenständige Anwendung direkt auf der Operating-System- und Dateisystem-Ebene des Webservers ausgeführt wird.

• Server-Level File-Scanning: Scannt die Dateien auf dem Server unabhängig von WordPress. Es verbraucht keinerlei PHP-Ressourcen von WordPress, benötigt keinen Datenbank-Speicherplatz und beeinträchtigt die TTFB-Ladezeit der Website nicht.
• Präzises Code-Patching: Erkennt veraltete Core-Dateien oder verwundbare Plugins und korrigiert die spezifische Sicherheitslücke direkt im Quellcode der betroffenen PHP-Datei, ohne dass ein vollständiges Plugin-Update erforderlich ist. Das Risiko, dass ein Major-Update das Website-Layout beschädigt, wird dadurch minimiert.
• Automatische Quarantäne & Revert: Entdeckter Schadcode wird isoliert und in Quarantäne verschoben. Eingespielte Patches können bei Kompatibilitätsproblemen im Server-Dashboard schrittweise rückgängig gemacht werden.
• Nachteile: Bietet keine Funktionen auf Applikationsebene wie Zwei-Faktor-Authentifizierung (2FA), Passwort-Richtlinien oder das Verstecken der wp-login.php. Es schützt primär vor bekannten Code-Lücken und Malware, dient jedoch nicht als Bot-Sperre für Formulare.

3. Kadence Security, früher Solid Security / SolidWP / iThemes Security (Klassisches Plugin)

Kadence Security agiert im Kern nicht als Deep-Packet-Inspection-Firewall, sondern als Härtungs- und Zugriffs-Manager.

• System- & Konfigurations-Hardening: Anstatt jeden Request wie eine WAF tiefgehend zu analysieren, schreibt Kadence Security feste Regeln in die .htaccess / nginx.conf sowie die wp-config.php (z. B. Verzeichnis-Browsing sperren, Schreibrechte einschränken, Header setzen).
• Network Brute Force Protection: Meldet fehlerhafte Login-Versuche an ein zentrales Cloud-Netzwerk. Versucht ein Bot es Minuten später bei einer anderen Website im selben Netzwerk, wird die IP dort sofort blockiert.
• Passkey & Modern Auth: Bietet Integrationen für Passkeys, erzwungene 2FA, Passwort-Komplexität und Session-Lockouts.
• Nachteile: Kann bereits tief im Quellcode versteckten Schadcode oder Zero-Day-Exploits im laufenden Betrieb nicht erkennen, da kein aktiver Dateivergleich stattfindet. Bei spezialisiertem Managed-WordPress-Hosting sind die meisten Hardening-Regeln auf Serverebene bereits abgedeckt, was das Plugin weitgehend redundant macht.

4. WP Cerber Security (Spezial-Plugin)

WP Cerber ist eine spezialisierte Bot-Defense- und Heuristik-Engine mit starkem Fokus auf Verhaltensanalyse.

• Cerber Anti-Spam & Bot-Detection: Analysiert das Verhalten von Formular-Eingaben und HTTP-Headern. Erkennungsmuster basieren auf Ausfüllgeschwindigkeiten, unsichtbaren Feldern (Honeypots) und abweichenden Request-Strukturen.
• Granulare Schnittstellen-Sperre: Erlaubt die selektive Steuerung der WordPress REST-API (z. B. gezieltes Sperren des Endpunkts /wp/v2/users, über den Bots Benutzernamen auslesen).
• Schutz der wp-login.php: Ermöglicht das komplette Umleiten der Login-URL und blockiert IP-Subnetze (CIDR-Blöcke) dynamisch nach fehlgeschlagenen Anmeldeversuchen.
• Nachteile: Aufgrund von Richtlinien-Disputen nicht im offiziellen WordPress.org-Repository gelistet. Updates müssen extern bezogen werden, was automatisierte Deployment-Pipelines erschwert.

5. Patchstack (Cloud-API + Schlankes Agent-Plugin)

Patchstack nutzt das Prinzip des virtuellen Patchens (vPatching) über eine externe Cloud-Infrastruktur.

• Funktionsweise von vPatching: Wird in einem Plugin eine Sicherheitslücke entdeckt, sendet Patchstack in Echtzeit eine mikroskopisch kleine Firewall-Regel an die Instanz. Diese Regel filtert exakt den bösartigen Parameter heraus, der die spezifische Lücke ausnutzen würde – noch bevor der Entwickler ein offizielles Update bereitstellt.
• Minimaler Resource Footprint: Verzichtet auf lokale Datei-Scans und Datenbank-Traffic-Logs. Das Plugin agiert lediglich als schlanker Agent zum Abruf der vPatch-Regeln von der Patchstack-API.
• Zentralisiertes Management: Bietet ein externes SaaS-Dashboard zur plattformübergreifenden Überwachung von Plugin-Versionen und Schwachstellen über hunderte Instanzen hinweg.
• Nachteile: Schützt zielgerichtet gegen dokumentierte Plugin-Schwachstellen, ist jedoch kein allgemeiner Malware-Cleaner für manuell kompromittierte Zugangsdaten.

Raidboxes-Empfehlung: Sicherheitsfunktionen wie IP-Blocking, Malware-Quarantäne und DDoS-Abwehr gehören architektonisch auf die Ebene der Server-Infrastruktur. Wenn serverseitige Werkzeuge (wie Patchman) oder globale WAFs die Dateiebenen absichern, reicht auf Applikationsebene ein schlankes Plugin zur Zwei-Faktor-Authentifizierung (2FA) völlig aus, um maximale Sicherheit ohne Performance-Einbußen zu garantieren.

---

Notfall-Plan: Ich wurde gehackt – was nun?

Wenn Schadcode eingeschleust wurde, ist strukturiertes Handeln entscheidend. In einer Krisensituation hilft eine klare Abgrenzung der Zuständigkeiten:

Im Ernstfall sollten die folgenden Schritte in exakt dieser Reihenfolge durchlaufen werden:

1. Quarantäne
2. Passwort-Reset
3. Clean-Up / Backup
4. Ursachenforschung

1. Quarantäne & Wartungsmodus

Aktiviere umgehend den Wartungsmodus oder sperre den Zugriff auf die Website für externe Besucher via .htaccess, sobald Schadcode vermutet wird. Das schützt Besucher und verhindert, dass Suchmaschinen die infizierte Seite crawlen.

Wird ein Hack zu spät isoliert, entstehen rasch Konsequenzen, die weit über das technische Problem hinausgehen:

• DSGVO-Meldepflicht (72-Stunden-Frist): Sobald ein Risiko für Nutzerdaten besteht (z. B. abgeflossene Daten aus Kontaktformularen oder Shops), schreibt die DSGVO eine Meldung an die Datenschutzbehörde innerhalb von 72 Stunden vor. Formulare zur Meldung einer Datenpanne findest du bei der jeweiligen Landesbehörde, z.b. baden-wuerttemberg.datenschutz.de, ldi-fms.nrw.de, datenschutz.hessen.de oder datenschutz.rlp.de. Stehen innerhalb der 72-Stunden-Frist noch nicht alle Details fest (z. B. die genaue Anzahl betroffener Datensätze), reiche das Dokument als vorläufige Erstmeldung ein. Gemäß Art. 33 Abs. 4 DSGVO können weitere Informationen schrittweise und ohne unbegründete Verzögerung nachgereicht werden.
• Ranking- und Reputationsverlust: Kennzeichnet Google eine Seite mit dem Hinweis „Diese Website wurde eventuell gehackt“ oder entfernt sie temporär aus dem Index, bricht der organische Traffic sofort ein. Der Wiederaufbau des vorherigen Niveaus kann Monate dauern.
• E-Mail-Blacklisting: Wird der Webspace zum Versenden von Spam-Mails missbraucht, landet die IP-Adresse des Servers schnell auf globalen Blacklists (wie Spamhaus). In der Folge kommen auch reguläre Firmen-E-Mails nicht mehr beim Empfänger an.

2. Passwort- & Salt-Reset durchführen

Angreifer hinterlassen nach einem Einbruch häufig Hintertüren für spätere Zugriffe.

• Ändere die Passwörter aller WordPress-Benutzer mit Administrator-Rollen.
• Ändere die Passwörter für FTP, SSH und die MySQL-Datenbank beim Hoster.
• Tausche die Sicherheitsschlüssel (Salts) in der wp-config.php aus, um alle aktiven Sitzungen sofort zu beenden.

3. Bereinigung (Clean-Up) oder Backup-Import

• Option A (Import über Backup): Der schnellste und sicherste Weg. Spiele das letzte garantierte, saubere Backup ein (bevor der Hack stattfand). Ändere direkt danach alle Passwörter und schließe umgehend die Lücke, über die der Angriff erfolgte.
• Option B (Manuelle Bereinigung): Wenn kein sauberes Backup existiert, reicht das bloße Löschen auffälliger Dateien meist nicht aus.
  1. Lade frische Kopien von WordPress-Core, Themes und Plugins aus offiziellen Quellen herunter.
  2. Ersetze die Ordner /wp-admin/ und /wp-includes/ sowie alle Core-Dateien im Hauptverzeichnis durch die unberührten Originaldateien.
  3. Lösche bestehende Plugins und Themes vollständig und installiere sie aus offiziellen Quellen neu.
  4. Scanne den Ordner /wp-content/uploads/ manuell nach .php-Dateien und lösche diese (ausführbare PHP-Dateien haben in diesem Ordner nichts zu suchen).

Das händische ‚Säubern‘ einer bereits gehackten Instanz ohne sauberes Backup führt in vielen Fällen nach einigen Tagen zu einer erneuten Infektion, weil versteckte Backdoors übersehen wurden. Ein sauberes Restore auf Serverebene ist in den meisten Fällen die nachhaltigere Lösung.

4. Ursachenforschung & Google Search Console

Ermittle, wie der Angreifer in das System gelangen konnte. Prüfe dazu die Server-Logdateien (Access Logs) zum Zeitpunkt des Angriffs auf auffällige POST-Requests oder Aufrufe von unüblichen .php-Dateien. Fehlt dieser Schritt, wird die Website über dieselbe Lücke innerhalb kurzer Zeit erneut infiziert.

Hat Google die Seite bereits markiert, beantrage nach der vollständigen Bereinigung über die Google Search Console unter Sicherheitsprobleme eine erneute Überprüfung.

---

Checkliste zur WordPress-Sicherheit

---

Häufig gestellte Fragen (FAQ) zu WordPress Sicherheit