tl;dr

WordPress ist das meistgenutzte CMS der Welt — und damit auch das meistangegriffene. Fast alle Angriffe laufen automatisiert ab, zielen auf bekannte Schwachstellen in Plugins, schwache Zugangsdaten oder offene Schnittstellen ab. Wer seine Website nicht aktiv pflegt, lebt permanent im offenen Angriffsfenster. Dieser Leitfaden erklärt alle relevanten Angriffsvektoren und was Sie konkret dagegen tun können.

Inhaltsverzeichnis

Die Zahlen, die man kennen sollte
Warum Plugins das größte Einfallstor sind
Echte WordPress Sicherheitslücken aus der Praxis
Wie Hacker Ihre Website finden – ohne je davon gehört zu haben
Die unterschätzte Gefahr: Plugins ohne Patch
Login-Sicherheit: Der zweithäufigste Angriffsvektor
Weitere Sicherheitslücken: XML-RPC, SQL-Injection, XSS
Was passiert, wenn Ihre WordPress-Website gehackt wurde
Aktiver Schutz: Firewalls und Malware-Scanner
Backups: Das letzte Sicherheitsnetz
Der häufigste Fehler beim Thema Updates
WordPress Sicherheitslücken schließen: Was konkret hilft
FAQ: WordPress Sicherheitslücken

1. Die Zahlen, die man kennen sollte

WordPress läuft auf über 43 % aller Websites weltweit — das entspricht mehr als 800 Millionen Installationen. Diese Verbreitung ist Segen und Fluch zugleich: Je mehr Websites auf derselben Plattform laufen, desto lohnender wird es für Angreifer, Schwachstellen in dieser Plattform zu finden und automatisiert auszunutzen.

Die WordPress-Vulnerability-Datenbanken wie WPScan und Patchstack dokumentieren das kontinuierlich. Allein 2023 wurden über 5.000 neue Schwachstellen in WordPress-Plugins registriert — jede davon mit einer eindeutigen CVE-Nummer dokumentiert, die als globaler Bezeichner für genau diese Lücke gilt. Rund 97–99 % aller WordPress-Angriffe nutzen Sicherheitslücken in Plugins aus — nicht in WordPress selbst.

Und noch eine Zahl: Laut Branchenberichten gab es allein 2020 rund 4,3 Milliarden Versuche, WordPress-Sicherheitslücken auszunutzen. Fast ein Drittel des gesamten Internet-Traffics besteht inzwischen aus schädlichen Bots — Tendenz steigend.

Was das für eine durchschnittliche WordPress-Website bedeutet: Wenn Sie gerade 20 aktive Plugins im Einsatz haben, sind statistisch mehrere davon zu irgendeinem Zeitpunkt verwundbar. Die Frage ist nicht ob, sondern wann — und ob Sie dann schon aktualisiert haben.

Was angegriffen wird	Anteil an Angriffen
Plugins	~97–99 %
Themes	< 3 %
WordPress Core	< 1 %
Hosting-Infrastruktur	< 1 %

Die Verteilung ist eindeutig. Und sie hat direkte Konsequenzen dafür, wie man über WordPress-Sicherheit nachdenken sollte.

2. Warum Plugins das größte Einfallstor sind

WordPress Core wird von einem großen Team aktiv gewartet. Sicherheitsupdates kommen schnell, werden gut getestet und sind breit dokumentiert.

Plugins entstammen einer völlig anderen Realität.

Viele stammen von Einzelentwicklern oder kleinen Teams, die keine eigene Security-Abteilung haben. Sie unterliegen dabei keinerlei Weisungsbefugnis durch WordPress und sind für die Weiterentwicklung und Sicherheit ihrer Programme ausschließlich selbst verantwortlich. Einige werden nach dem initialen Launch kaum noch weiterentwickelt. Andere setzen veraltete Code-Bibliotheken ein, weil niemand die Zeit hatte, sie zu aktualisieren.

Da WordPress Open Source ist, kann theoretisch jeder den Code einsehen — auch Angreifer. Sobald eine Schwachstelle in einem Plugin bekannt wird und eine CVE veröffentlicht ist, beginnen automatisierte Bots, das gesamte Internet nach Websites zu durchsuchen, die dieses Plugin in der verwundbaren Version betreiben. Das schafft eine Angriffsfläche, die ständig wächst — und die viele Website-Betreiber schlicht nicht auf dem Schirm haben, weil das Backend auf den ersten Blick genauso aussieht wie immer.

Das oft vergessene Risiko deaktivierter Plugins: Auch deaktivierte Plugins sind angreifbar. Die Dateien liegen weiterhin auf dem Server und sind über bekannte Dateipfade erreichbar. Automatisierte Angriffs-Bots prüfen auf Verdacht, ob bestimmte Plugin-Verzeichnisse existieren — egal ob das Plugin aktiv ist oder nicht. Deaktiviert bedeutet nicht geschützt. Wer ein Plugin nicht braucht, muss es vollständig löschen.

3. Echte WordPress Sicherheitslücken aus der Praxis

Die folgenden Beispiele zeigen, wie schnell aus einer bekannten Schwachstelle ein massives Problem werden kann:

Rank Math (2020): Rechteübernahme auf 200.000 Websites

Anfang 2020 enthielt das beliebte SEO-Plugin „Rank Math" zwei kritische Sicherheitslücken. Nicht autorisierte Benutzer konnten damit auf über 200.000 Websites Benutzerrechte gewähren oder widerrufen — ohne sich einzuloggen. Das Problem wurde per Update behoben, aber nur für diejenigen, die es auch eingespielt hatten.

WP File Manager (September 2020): Vollständige Website-Übernahme

Das Plugin „WP File Manager", installiert auf über 700.000 Websites, erlaubte Hackern unerlaubte Datei-Uploads und -Änderungen — bis hin zur vollständigen Übernahme der Website. Die Sicherheitslücke wurde massiv ausgenutzt, bevor ein Update erschien.

WPBakery Page Builder (Oktober 2020): 4,3 Millionen betroffene Seiten

Eine Schwachstelle im populären Page Builder ermöglichte das Einschleusen von schädlichem Code und die Übernahme von Administratorenrechten. Mit rund 4,3 Millionen betroffenen Websites war das eine der schwersten WordPress-Sicherheitslücken des Jahres.

HT Contact Form (Juli 2025): CVSS 9.8 — maximale Kritikalität

Das Plugin „HT Contact Form" enthielt gleich drei kritische Lücken (CVE-2025-7340, CVE-2025-7341, CVE-2025-7360) mit CVSS-Bewertungen von 9.1 bis 9.8. Angreifer konnten ohne jede Authentifizierung beliebige Dateien hochladen, löschen oder verschieben — darunter die zentrale Konfigurationsdatei wp-config.php. Wer diese löscht, versetzt eine Website in den Ersteinrichtungszustand und öffnet dem Angreifer Tür und Tor. Über 10.000 Websites waren betroffen.

Ein CVSS-Score von 9.8 bedeutet in der Praxis: sofort handeln. Nicht nach dem nächsten regulären Update-Zyklus. Sofort.

Diese Beispiele sind keine Einzelfälle. Sie sind der Normalzustand.

4. Wie Hacker Ihre Website finden – ohne je davon gehört zu haben

Der größte Irrtum, den ich in Gesprächen mit Kunden regelmäßig höre: „Warum sollten die ausgerechnet meine Website angreifen? Ich bin doch keine bekannte Marke."

Das ist ein fundamentales Missverständnis davon, wie moderne Angriffe auf WordPress-Sicherheitslücken funktionieren.

Automatisiertes Scanning: kein Mensch, kein Ziel

Der Angreifer ist selten ein Mensch, der Ihre Website kennt und sich gezielt für Sie entschieden hat. Der Angreifer ist ein automatisierter Scanner, der das gesamte Internet nach bestimmten Mustern durchsucht — wie ein Einbrecher, der nachts an tausend Türgriffen rüttelt und irgendwann eine offene findet.

Der Ablauf ist verblüffend simpel:

Schritt 1 – CVE wird veröffentlicht: Eine neue Schwachstelle in einem populären Plugin (z.B. WooCommerce, Elementor, Contact Form 7) wird mit einer CVE-Nummer in einer Vulnerability-Datenbank gelistet — inklusive genauer Beschreibung, wie die Lücke ausgenutzt werden kann.

Schritt 2 – Scanner suchen nach diesem Plugin: Automatisierte Tools durchforsten das Netz nach Websites, die dieses Plugin in der verwundbaren Version einsetzen. Das dauert keine 24 Stunden.

Schritt 3 – Exploit: Wer die Lücke noch nicht geschlossen hat, ist angreifbar. Unabhängig von Größe, Bekanntheit oder Umsatz der dahinterstehenden Organisation.

Ihre Website braucht keine Feinde. Sie braucht nur eine veraltete Plugin-Version und ein paar Stunden Zeit.

Was nach einem erfolgreichen Angriff passiert

Der Angreifer will meistens nicht Ihre Daten. Er will Ihre Infrastruktur. Die häufigsten Szenarien:

SEO-Spam-Injection: Ihre Website wird genutzt, um Tausende versteckte Spam-Links zu platzieren. Google straft Sie dafür ab, nicht den Angreifer.
Phishing-Seiten: Über Ihr Hosting werden betrügerische Login-Seiten für andere Dienste ausgespielt — perfekte Nachbauten von Microsoft 365, PayPal oder Banking-Oberflächen.
Botnet-Integration: Ihr Server wird Teil eines Netzwerks, das weitere Angriffe auf Dritte fährt.
Krypto-Mining: Ihre Server-Ressourcen werden im Hintergrund genutzt, ohne dass Sie es merken.
Backdoors: Versteckte Zugänge werden hinterlegt, über die der Angreifer auch nach einer Bereinigung wieder einsteigen kann.

Das alles passiert oft unbemerkt. Keine offensichtlichen Anzeichen, kein Ausfall, kein Alarm — bis Google Ihre Domain auf eine Blacklist setzt oder Ihr Hoster das Konto sperrt.

5. Die unterschätzte Gefahr: Plugins ohne Patch

Eine besonders unangenehme Kategorie sind Plugins mit bekannter Schwachstelle, für die es noch kein Update gibt — sogenannte Zero-Day-Sicherheitslücken.

WPScan dokumentiert regelmäßig solche ungepatchten Schwachstellen — Lücken, die öffentlich bekannt sind und eine CVE-Nummer haben, aber vom Plugin-Entwickler noch nicht geschlossen wurden. Manchmal weil das Update in Entwicklung ist. Manchmal weil das Plugin schlicht nicht mehr gewartet wird.

Das Zeitfenster zwischen CVE-Veröffentlichung und Update-Installation ist der kritischste Moment. Wer das manuell managt — also erst dann aktualisiert, wenn er irgendwann ins Backend schaut — lebt in diesem Fenster permanent. In der Sicherheitsbranche spricht man hier von einem N-Day-Exploit: eine bekannte Lücke mit verfügbarem Patch, der schlicht noch nicht eingespielt wurde. Statistisch sind N-Days für weit mehr erfolgreiche Angriffe verantwortlich als echte Zero-Days.

Abandoned Plugins: die stille Gefahr

Noch problematischer sind Plugins, die aus dem WordPress-Verzeichnis entfernt wurden oder deren Entwickler den Support eingestellt hat. Diese Plugins erhalten keine weiteren Sicherheits-Updates mehr, egal wie kritisch eine neu entdeckte Lücke ist — und können damit zur dauerhaften Zero-Day-Schwachstelle werden.

Ein Plugin, das seit 18 Monaten kein Update mehr erhalten hat, ist nicht zwingend gefährlich. Aber es ist ein Warnsignal. Wenn es gleichzeitig in Vulnerability-Datenbanken auftaucht, wird es gefährlich — und es muss ersetzt werden.

Neben Plugin-Schwachstellen ist der WordPress-Login das zweithäufigste Angriffsziel. Der Grund: Der Login-Pfad (/wp-admin oder /wp-login.php) ist bei jeder Standard-WordPress-Installation identisch — und damit für jeden Angreifer bekannt.

Brute-Force-Angriffe: Statistik statt Zielauswahl

Brute-Force-Angriffe sind simpel und deshalb wirkungsvoll: Automatisierte Bots testen tausende Benutzernamen-Passwort-Kombinationen durch, angefangen mit den häufigsten Passwörtern aus veröffentlichten Datenleck-Listen. Dabei geht es nicht um Sie persönlich — der Bot arbeitet schlicht eine Liste ab, bis eine Kombination funktioniert.

Besonders problematisch ist der Standard-Benutzername „admin": Viele WordPress-Installationen laufen noch immer mit diesem voreingestellten Zugangsnamen, der bei jedem Brute-Force-Bot als erster Kandidat geprüft wird. Wer den Benutzernamen „admin" auf einen individuellen Namen ändert, setzt dem bereits einen kleinen, aber sinnvollen Riegel vor.

Ein weiteres Problem: WordPress zeigt standardmäßig an, ob ein eingegebener Benutzername korrekt ist — auch wenn das Passwort falsch war. Diese Fehlermeldung hilft Angreifern, den richtigen Benutzernamen zu bestätigen, bevor sie das Passwort knacken.

Was ein sicheres Passwort wirklich bedeutet

Sonderzeichen-Kauderwelsch wie H3!%daR$2024 ist zwar technisch stark, aber kaum zu merken. Eine praxistauglichere Alternative sind Passphrasen: drei zufällige Wörter kombiniert, mindestens 17 Zeichen lang, ohne Leerzeichen. Beispiel: TaubeSchlittschuhKlavier. Ab 17 Zeichen wird ein Passwort für Brute-Force-Angriffe praktisch unknackbar.

Selbst wenn ein Passwort geknackt wird, ist ein Account mit 2FA geschützt. Beim Login wird zusätzlich ein zeitbasierter Einmalcode abgefragt — generiert von einer App auf dem Smartphone (z.B. Google Authenticator, Microsoft Authenticator). Wer den Code nicht hat, kommt nicht rein.

2FA ist heute kein optionales Feature mehr. Es ist die effektivste Einzelmaßnahme zum Schutz des Admin-Zugangs — und schützt auch dann, wenn Zugangsdaten durch Phishing oder ein Datenleck eines anderen Dienstes kompromittiert wurden.

Ohne Begrenzung kann ein Bot unbegrenzt Passwörter durchprobieren. Ein Login-Limit sperrt eine IP-Adresse nach einer definierten Anzahl fehlgeschlagener Versuche. Sinnvolle Einstellung: drei bis fünf Fehlversuche, danach Sperrzeit von 30 Minuten bis 24 Stunden.

Da der WordPress-Login immer unter /wp-admin oder /wp-login.php erreichbar ist, können Bots diesen Pfad blind ansteuern. Eine individuelle Login-URL entzieht automatisierten Brute-Force-Angriffen die bekannte Einstiegsmöglichkeit. Kein Allheilmittel, aber eine sinnvolle zusätzliche Hürde.

7. Weitere Sicherheitslücken: XML-RPC, SQL-Injection, XSS

Die XML-RPC-Schnittstelle: Brute Force auf Steroiden

Die Datei xmlrpc.php im WordPress-Stammverzeichnis ist eine weitgehend unbekannte, aber gefährliche Schwachstelle. Über XML-RPC lassen sich tausende Loginversuche in einer einzigen Anfrage bündeln. Normale Login-Schutzmechanismen, die einzelne fehlgeschlagene Versuche zählen, greifen hier oft nicht. Darüber hinaus kann die Schnittstelle für DDoS-Angriffe über die Pingback-Funktion missbraucht werden — mit dem Ergebnis, dass der Hoster das Konto sperrt, obwohl der Betreiber selbst keine Schuld trägt.

99 % aller WordPress-Websites benötigen XML-RPC nicht. Für sie gilt: Schnittstelle dauerhaft blockieren, entweder über ein Sicherheits-Plugin oder direkt per .htaccess-Eintrag.

Wie man prüft, ob XML-RPC aktiv ist: https://ihredomain.de/xmlrpc.php im Browser aufrufen. Erscheint die Meldung „XML-RPC server accepts POST requests only", ist die Schnittstelle aktiv und angreifbar.

SQL-Injection

Über schlecht abgesicherte Formulare, Suchfelder oder Kommentarfunktionen lassen sich manipulative Datenbankbefehle einschleusen. Das Ergebnis: sensible Daten werden extrahiert oder die gesamte Datenbank manipuliert. SQL-Injection gehört seit Jahren zu den häufigsten Angriffsmethoden auf Webanwendungen — und ist bei veralteten Plugins ein klassisches Einfallstor, weil ältere Code-Bibliotheken Eingaben oft nicht korrekt bereinigen.

Cross-Site-Scripting (XSS)

Bei Cross-Site-Scripting (XSS) wird bösartiger JavaScript-Code über ungesicherte Eingabefelder — Kommentare, Kontaktformulare, Suchfelder — in die Website eingeschleust und im Browser des Besuchers ausgeführt. Mögliche Folgen: Diebstahl von Session-Cookies, Weiterleitung auf Phishing-Seiten, ungewollte Downloads. Auch hier gilt: aktuell gehaltene Plugins sind deutlich seltener betroffen als veraltete.

Unsichere Hosting-Umgebung

Server ohne ausreichende Firewalls, veraltete PHP-Versionen und fehlende Absicherung der Verzeichnisstruktur erhöhen das Risiko unabhängig davon, wie gut die WordPress-Installation selbst gepflegt ist. Ein guter Managed-Hosting-Anbieter hält PHP-Versionen aktuell, bietet integrierte DDoS-Abwehr und setzt eine Web Application Firewall (WAF) auf Serverebene ein.

8. Was passiert, wenn Ihre WordPress-Website gehackt wurde

Das Tückische an einem erfolgreichen Angriff: Er bleibt oft wochenlang unbemerkt. Der Angreifer hat kein Interesse daran, dass Sie ihn entdecken — er nutzt Ihre Infrastruktur still im Hintergrund.

Typische Anzeichen einer kompromittierten Website

Google zeigt eine rote Warnseite mit „Diese Website wurde möglicherweise gehackt"
Besucher berichten von unbekannten Weiterleitungen auf fremde Seiten
Der Hoster sperrt das Hosting-Konto wegen Malware-Verbreitung
Im Google-Index tauchen Seiten auf, die Sie nie erstellt haben (erkennbar über site:ihredomain.de)
Im Seitenquellcode finden sich unbekannte Links oder JavaScript-Blöcke
Der Server ist merklich langsamer als üblich — ein mögliches Zeichen für Krypto-Mining oder Bot-Traffic

Die drei häufigsten Hack-Typen bei WordPress

Fake Login Pages (Phishing): Der Angreifer erstellt Seiten, die täuschend echten Login-Oberflächen von Microsoft 365, PayPal oder Banken ähneln. Diese Seiten laufen unter Ihrer Domain — der Schaden für Ihre Reputation ist erheblich, auch wenn Sie selbst kein Ziel der Attacke sind.

Redirect-Hacks: Besucher, die über Google auf Ihre Website kommen, werden automatisch auf externe Seiten weitergeleitet. Besonders tückisch: Eingeloggte Admins sehen die Weiterleitung oft nicht, weil der Schadcode nur für Besucher ohne aktive Session ausgelöst wird.

Malware und Backdoors: Schadhafter Code wird in Dateien oder die Datenbank eingeschleust, der im Hintergrund agiert — SEO-Spam injiziert, Server-Ressourcen für Krypto-Mining nutzt oder als Backdoor für spätere Zugriffe fungiert.

Was nach einer Infektion zu tun ist

Backups sind das wichtigste Werkzeug — aber nur, wenn sie sauber sind. Hacker verankern sich oft Wochen vor dem sichtbaren Schaden. Ein Backup vom Vortag kann bereits infiziert sein. Deshalb gilt: Backups extern und über einen langen Zeitraum aufbewahren.

Nach der Bereinigung: alle Passwörter ändern, Sicherheitsschlüssel in der wp-config.php erneuern und alle aktiven Sessions forciert abmelden, damit hinterlassene Backdoor-Sessions ungültig werden. Anschließend Google über die Search Console informieren und einen Review-Request stellen, damit Blacklist-Einträge aufgehoben werden.

9. Aktiver Schutz: Firewalls und Malware-Scanner

Wer nur auf Updates setzt, agiert reaktiv. Wer zusätzlich eine Firewall und einen Malware-Scanner einsetzt, fügt eine aktive Schutzschicht hinzu.

Was eine WordPress Firewall (WAF) leistet

Eine Web Application Firewall (WAF) filtert eingehende Anfragen, bevor sie WordPress erreichen — und blockiert bekannte Angriffsmuster automatisch. Sie schützt gegen SQL-Injection, Cross-Site-Scripting, Brute-Force-Angriffe und viele weitere Angriffsvektoren. Gute Firewalls arbeiten mit einer kontinuierlich aktualisierten Datenbank bekannter Bedrohungen.

Bei Zero-Day-Sicherheitslücken kann eine Cloud-basierte WAF besonders wertvoll sein: Sie kann neue Schutzregeln innerhalb von Minuten weltweit ausrollen — noch bevor ein offizieller Plugin-Patch verfügbar ist. Das nennt sich virtueller Patch.

Zwei verbreitete Ansätze:

Wordfence ist das meistinstallierte Sicherheits-Plugin für WordPress (über 5 Millionen aktive Installationen). Die kostenlose Version bietet WAF, Brute-Force-Schutz, Login-Sicherheit mit 2FA und einen Malware-Scanner. Der Nachteil der Gratis-Version: Neue Bedrohungs-Signaturen werden mit 30 Tagen Verzögerung eingespielt.

NinjaFirewall ist ressourcenschonender und greift als sogenannte „Pre-PHP-Firewall" noch vor dem Start von WordPress ein — was es schwieriger macht, sie zu umgehen.

Grundsätzlich gilt: Immer nur ein Sicherheits-Plugin gleichzeitig installieren.

Malware-Scanner: Was sie können — und was nicht

Malware-Scanner durchsuchen Ihre WordPress-Dateien nach bekannten Schadcode-Mustern. Die Methoden unterscheiden sich dabei erheblich — mehr dazu im Glossarartikel zu Web Application Firewalls. Ein Scan-Ergebnis von „Keine Bedrohungen gefunden" bedeutet nicht zwingend, dass die Website sauber ist — sondern nur, dass der eingesetzte Scanner nichts gefunden hat.

Datei-Monitoring

Ein oft unterschätztes Feature: Datei-Monitoring erstellt einen Snapshot aller Dateien und erkennt Änderungen. Wenn ein Angreifer eine neue PHP-Datei im Uploads-Ordner ablegt, wird der Betreiber per E-Mail benachrichtigt — bevor der Schaden eskaliert.

10. Backups: Das letzte Sicherheitsnetz

Kein System ist zu 100 % sicher. Wer das akzeptiert, versteht, warum Backups keine optionale Zusatzmaßnahme sind — sondern die Grundvoraussetzung dafür, überhaupt reagieren zu können.

Was ein brauchbares Backup ausmacht

Ein Backup, das auf demselben Server liegt wie die Website, ist im Ernstfall wertlos — wenn der Server kompromittiert ist, ist das Backup es möglicherweise auch. Sinnvolle Backups erfüllen drei Kriterien:

Extern gespeichert: Cloud-Speicher (z.B. Google Drive, Dropbox) oder ein separater Server — nicht auf demselben Hosting-Account.

Regelmäßig erstellt: Tägliche Backups sind Standard. Für Websites mit häufigen Inhaltsänderungen kann eine noch höhere Frequenz sinnvoll sein.

Ausreichend historisch: Malware verankert sich oft Wochen vor dem sichtbaren Angriff — das Backup vom Vortag ist dann bereits infiziert. Mindestens 30 Tage Backup-Historie ermöglicht es, auf einen wirklich sauberen Stand zurückzugehen.

Hosting-Backups sind kein Ersatz

Viele Hoster erstellen automatisch tägliche Backups. Das ist besser als nichts — aber es ersetzt keine eigene Backup-Strategie. Hosting-Backups können überschrieben werden, liegen auf demselben System und sind im Ernstfall möglicherweise nicht schnell genug verfügbar.

Das Backup muss getestet werden

Ein Backup, das nie wiederhergestellt wurde, ist ein unbestätigtes Versprechen. Wer wirklich vorbereitet ist, testet das Einspielen auf einer Staging-Umgebung — bevor es im Ernstfall nötig wird.

11. Der häufigste Fehler beim Thema Updates

„Ich spiele Updates ein, wenn ich ins Backend schaue."

Das ist keine Update-Strategie. Das ist Zufall mit Wartungsoptik.

Das Problem ist nicht die Absicht — das Problem ist die Verzögerung. Wenn Sie alle vier Wochen ins Backend schauen, haben Sie im Schnitt ein 14-tägiges Fenster, in dem eine bekannte Lücke ungepatcht ist — ein offenes Fenster für N-Day-Exploits. In diesem Fenster suchen Scanner bereits aktiv danach.

Gleichzeitig ist blindes Einspielen jedes Updates ebenfalls riskant: Manche Updates brechen Kompatibilitäten und können Funktionen zerstören. Besonders bei Major-Versionssprüngen oder komplexen Plugin-Kombinationen. Und auch automatische Updates helfen nur, wenn danach jemand prüft, ob die Website noch korrekt funktioniert.

Das Prinzip, das wirklich funktioniert: strukturiertes Update-Management mit Vorab-Backup, Kompatibilitätsprüfung und anschließender Funktionskontrolle — in einem festen Rhythmus, nicht dann, wenn Zeit übrig ist.

12. WordPress Sicherheitslücken schließen: Was konkret hilft

Bevor Sie irgendetwas anderes tun, beantworten Sie diese drei Fragen:

1. Wissen Sie, welche Plugins aktuell installiert sind — inklusive inaktiver? Inaktive Plugins sind genauso angreifbar wie aktive.

2. Wann wurde zuletzt geprüft, ob eines Ihrer Plugins in einer Vulnerability-Datenbank mit einer CVE gelistet ist? Das ist eine andere Frage als „Wann haben Sie Updates eingespielt". Eine Lücke kann bekannt sein, bevor ein Update verfügbar ist.

3. Gibt es ein aktuelles, extern gespeichertes Backup, das Sie sofort einspielen könnten? Nicht das automatische Hosting-Backup, das möglicherweise schon überschrieben oder auf demselben kompromittierten Server liegt.

Wenn Sie eine dieser Fragen nicht sicher beantworten können, ist das keine Kleinigkeit — es ist eine offene Tür.

Checkliste: WordPress Sicherheitslücken systematisch schließen

Alle Plugins und Themes auf dem neuesten Stand halten — mit Backup vor jedem Update und Funktionskontrolle danach
Inaktive Plugins vollständig löschen, nicht nur deaktivieren
Plugins aus dubiosen Quellen entfernen — gecrackte Premium-Plugins enthalten regelmäßig eingebaute Hintertüren und Malware
Plugin-Qualität vor der Installation prüfen: letztes Update-Datum, Installationszahlen (>2.000), aktive Entwickler-Kommunikation, Bewertungen
Vulnerability-Monitoring einrichten — proaktiv prüfen, ob installierte Plugins mit einer CVE in Sicherheitsdatenbanken auftauchen
XML-RPC deaktivieren, wenn nicht benötigt
Standard-Benutzernamen „admin" entfernen
Starke Passwörter (Passphrase, 17+ Zeichen) und 2FA für alle Admin-Zugänge
Login-Versuche begrenzen — Schutz vor Brute-Force-Angriffen (3–5 Fehlversuche, dann Sperrzeit)
Tägliche Backups extern speichern — mit mindestens 30 Tagen Aufbewahrung
PHP-Version aktuell halten — veraltete PHP-Versionen öffnen eigene Angriffsflächen
Web Application Firewall (WAF) einsetzen (z.B. Wordfence oder NinjaFirewall) — aber nur eines gleichzeitig
SSL-Zertifikat aktiv halten — alle Verbindungen müssen verschlüsselt laufen (HTTPS)
Benutzerrollen sauber vergeben — Redakteure brauchen keine Admin-Rechte

Was professionelle Website-Wartung darüber hinaus leistet

Professionelle Wartung löst das Problem nicht durch einmalige Maßnahmen, sondern durch kontinuierliche Aufmerksamkeit:

Updates mit Vorab-Backup und Kompatibilitätsprüfung — nicht blind auf Knopfdruck
Aktives Monitoring auf bekannte Schwachstellen und neue CVEs — nicht nur auf verfügbare Updates
Täglich erstellte Backups, extern gespeichert — nicht auf demselben Server, der im Angriffsfall kompromittiert sein könnte
Monatliche Übersicht über durchgeführte Maßnahmen und aktuellen Status

Das Ziel ist nicht, Angriffe zu 100 % auszuschließen. Das geht nicht. Das Ziel ist, das Angriffsfenster so klein zu halten, dass automatisierte Scanner nichts finden — und im Fall eines Vorfalls sofort reagieren zu können.

13. FAQ: WordPress Sicherheitslücken

Wie häufig werden WordPress-Websites angegriffen? Nahezu täglich — durch automatisierte Bots, nicht durch gezielte menschliche Angreifer. Fast ein Drittel des gesamten Internet-Traffics stammt von schädlichen Bots, die kontinuierlich nach bekannten WordPress-Sicherheitslücken suchen.

Woher kommen die meisten WordPress-Sicherheitslücken? Zu 97–99 % aus Plugins. WordPress Core selbst ist vergleichsweise sicher, weil es von einem großen, professionellen Team gepflegt wird. Plugins hingegen stammen oft von Einzelentwicklern ohne eigene Security-Prozesse und unterliegen keiner Qualitätskontrolle durch WordPress.

Sind deaktivierte Plugins ein Sicherheitsrisiko? Ja. Deaktiviert bedeutet nicht gelöscht — die Dateien liegen weiterhin auf dem Server und sind über bekannte Pfade erreichbar. Wer ein Plugin nicht nutzt, sollte es vollständig entfernen.

Wie schnell werden bekannte WordPress-Sicherheitslücken ausgenutzt? Sehr schnell. Sobald eine CVE veröffentlicht wird, beginnen automatisierte Scanner innerhalb von Stunden das Netz nach betroffenen Installationen zu durchsuchen. Wer nicht umgehend aktualisiert, ist angreifbar.

Was bedeutet ein hoher CVSS-Score bei einer Plugin-Schwachstelle? Der CVSS-Score bewertet den Schweregrad auf einer Skala von 0 bis 10. Werte ab 9.0 gelten als kritisch und bedeuten: sofort handeln. Der Score berücksichtigt, ob ein Angriff ohne Login möglich ist, wie komplex er ist und welchen Schaden er anrichten kann.

Was ist schlimmer: kein Update oder ein fehlerhaftes Update? Kein Update. Ein fehlerhaftes Update lässt sich mit einem aktuellen Backup rückgängig machen. Eine erfolgreiche Infektion durch eine bekannte Sicherheitslücke ist deutlich schwerer zu beheben und kann langfristige Schäden nach sich ziehen — von SEO-Blacklisting bis zu Reputationsverlust.

Reicht ein Sicherheits-Plugin zum Schutz aus? Nein. Eine WAF wie Wordfence ist ein wichtiges Werkzeug, ersetzt aber keine regelmäßige Wartung. Sie kann bekannte Angriffsmuster erkennen und blockieren — aber nicht verhindern, dass eine veraltete Plugin-Version eine neue Lücke enthält.

Wie erkenne ich, ob meine Website bereits kompromittiert wurde? Oft gar nicht auf den ersten Blick. Typische Warnsignale: Google zeigt eine Sicherheitswarnung für Ihre Domain, der Hoster sperrt das Konto, Besucher berichten von Weiterleitungen, oder im Google-Index tauchen Seiten auf, die Sie nie erstellt haben (site:ihredomain.de in der Google-Suche). Ein proaktives Monitoring auf Malware erkennt Probleme früher.

Was tun, wenn die Website gehackt wurde? Kein Backup einspielen, ohne sicherzustellen, dass es sauber ist — Hacker verankern sich oft Wochen vor dem sichtbaren Angriff. Nach der Bereinigung: alle Passwörter ändern, Sicherheitsschlüssel in der wp-config.php erneuern, alle aktiven Sessions forciert abmelden. Google über die Search Console informieren und einen Review-Request stellen, damit die Warnung aufgehoben wird.

Brauche ich SSL, wenn ich keine sensiblen Daten sammle? Ja. SSL verschlüsselt die gesamte Verbindung zwischen Server und Browser — nicht nur Formulardaten. Ohne SSL können Angreifer im gleichen Netzwerk den Datenverkehr mitlesen. Außerdem bevorzugt Google HTTPS-Websites in der Suche, und Browser zeigen bei HTTP-Seiten Sicherheitswarnungen an, die Besucher abschrecken.

Was ist der Unterschied zwischen einem Zero-Day und einer normalen Sicherheitslücke? Eine Zero-Day-Sicherheitslücke ist eine Schwachstelle, für die zum Zeitpunkt der Entdeckung noch kein Patch existiert. Eine normale Sicherheitslücke hat bereits ein verfügbares Update — das „nur" noch eingespielt werden muss. Letztere sind statistisch für die große Mehrheit aller erfolgreichen Angriffe verantwortlich.

Sie wissen nicht, wie es um Ihre Website steht? Im kostenlosen Erstgespräch schaue ich mir Ihre Plugin-Situation an und gebe Ihnen eine ehrliche Einschätzung — ohne Verpflichtung. Gespräch vereinbaren