Bei WordPress Sicherheit geht es vor allem um Plugins und um Zeit. Laut Patchstack steckten 91 Prozent der 2025 neu gemeldeten Sicherheitslücken in Plugins, und stark ausgenutzte Lücken wurden im Median schon fünf Stunden nach Bekanntwerden massenhaft angegriffen. Wer Updates ein paar Wochen sammelt, lässt die Tür in dieser Zeit offen.
Wie es aussieht, wenn das schiefgeht, habe ich vor vielen Jahren an einer gehackten WordPress-Seite erlebt. Sie war zur Spamschleuder geworden und leitete Besucher auf Seiten für Potenzmittel und Online-Casinos weiter. Für einen Unternehmer ist das mehr als ein technisches Problem: Wer über Google kommt und auf einer Casino-Seite landet, fragt nicht mehr an.
In diesem Artikel zeige ich dir, woher die Gefahr für WordPress-Websites kommt, was ein Angriff ein Unternehmen kostet, welche Maßnahmen in welcher Reihenfolge schützen, wie ich auf eine kritische Lücke auf meinem eigenen Server reagiert habe und wie ein Bot über die Kasse eines Shops kam.
Zusammenfassung
- Laut Patchstack steckten 2025 91 Prozent der neuen WordPress-Lücken in Plugins und 9 Prozent in Themes. Im WordPress-Kern wurden nur sechs Lücken gemeldet.
- Stark ausgenutzte Lücken werden im Median fünf Stunden nach Bekanntwerden massenhaft angegriffen. Sicherheitsupdates gehören deshalb sofort eingespielt und direkt danach getestet.
- Ein Hack kostet Anfragen, Rankings und die Bereinigung. Gehören personenbezogene Daten dazu, kann eine Meldepflicht nach der DSGVO entstehen.
- Die wichtigsten Schutzmaßnahmen sind Updates, abgesicherte Zugänge, ein abgeschalteter Datei-Editor, getestete Backups und möglichst wenige Plugins.
- Ein Sicherheits-Plugin ergänzt diese Maßnahmen, ersetzt sie aber nicht.
Woher die Gefahr für WordPress kommt
Die meisten Sicherheitslücken einer WordPress-Website stecken in Plugins, nicht im WordPress-Kern. Patchstack, ein Anbieter von Sicherheitslösungen für WordPress, hat für 2025 insgesamt 11.334 neue Lücken gezählt, 42 Prozent mehr als im Vorjahr. 91 Prozent davon betrafen Plugins, 9 Prozent Themes. Im Kern selbst wurden nur sechs Lücken gemeldet, alle mit niedriger Priorität (Patchstack-Bericht 2026).
Zwei weitere Zahlen aus demselben Bericht zeigen, warum es auf Zeit ankommt. Für 46 Prozent der Lücken gab es zum Zeitpunkt der Veröffentlichung noch keinen Fix vom Entwickler. Und stark ausgenutzte Lücken wurden im gewichteten Median fünf Stunden nach Bekanntwerden massenhaft angegriffen; etwa die Hälfte der Lücken mit großer Wirkung wird laut Patchstack innerhalb von 24 Stunden ausgenutzt.
Patchstack verkauft selbst Schutz gegen solche Lücken und hat damit ein Interesse an dramatischen Zahlen. Unabhängig davon betont die offizielle WordPress-Dokumentation: Ältere Versionen bekommen keine Sicherheitskorrekturen mehr, und die Informationen, um ihre bekannten Lücken auszunutzen, sind so gut wie sicher öffentlich (WordPress-Dokumentation). Wer nicht aktualisiert, ist damit für jeden lesbar angreifbar.
Was ein Hack ein Unternehmen kostet
Ein Hack kostet zuerst Vertrauen und Anfragen, dann Geld für die Bereinigung. Google beschreibt gehackte Inhalte als alles, was ohne Erlaubnis auf einer Website platziert wird, etwa eingeschleuster Code oder zusätzliche Spamseiten. Tückisch sind Weiterleitungen, die nur greifen, wenn jemand aus den Suchergebnissen kommt. Wer die eigene Adresse direkt im Browser aufruft, sieht nichts davon (Google Search Central). Der Inhaber merkt es also oft zuletzt.
Dazu kommen die Folgekosten:
- Bereinigung: Ein deutscher Anbieter, der diese Leistung verkauft, bereinigt gehackte WordPress-Seiten zum Festpreis ab 490 Euro, der Endpreis hängt vom Umfang des Befalls ab (Forge12).
- Rankings: Seiten, die gegen Googles Richtlinien verstoßen, erhalten laut Google möglicherweise ein niedrigeres Ranking.
- Datenschutz: Werden dabei personenbezogene Daten verletzt, etwa Anfragen oder Kundenkonten, muss der Verantwortliche das in der Regel unverzüglich und möglichst binnen 72 Stunden der Aufsichtsbehörde melden (Art. 33 DSGVO). Ich bin kein Anwalt; ob eine Meldung nötig ist, klärst du im Ernstfall mit deinem Datenschutzbeauftragten oder einem Anwalt.
- Ausfall: Jeder Tag, an dem die Website weiterleitet oder offline ist, kostet die Anfragen, die sonst gekommen wären.
Was für WordPress Sicherheit schützt, in dieser Reihenfolge
Gute WordPress Sicherheit ist zum größten Teil Routine. Ich arbeite die Maßnahmen in dieser Reihenfolge ab, weil die ersten am meisten Angriffsfläche schließen:
- Updates. Sicherheitsupdates spiele ich sofort ein, auch bei Plugins, und teste die Seite direkt danach. Alle anderen Updates laufen im festen Rhythmus über eine Testkopie. Wie das abläuft, steht im Artikel zur WordPress Wartung, wie die Testkopie aussieht, im Artikel zu WordPress Staging.
- Zugänge. Starke, einmalige Passwörter und eine Zwei-Faktor-Anmeldung für alle mit Zugang zum Backend. Die WordPress-Dokumentation empfiehlt die Anmeldung in zwei Schritten ausdrücklich als zusätzliche Sicherheitsmaßnahme. Administratorrechte bekommt nur, wer sie wirklich braucht.
- Datei-Editor abschalten. WordPress kann Theme- und Plugin-Dateien direkt im Backend bearbeiten. Laut WordPress-Dokumentation ist das oft das erste Werkzeug eines Angreifers, der sich anmelden konnte. Ein Eintrag in der wp-config.php schaltet den Editor ab (DISALLOW_FILE_EDIT).
- Backups mit Rücksicherungstest. Ein Backup ist die Versicherung für den Fall, dass alles andere versagt. Was ein Backup taugt, zeigt erst die Rücksicherung; mehr dazu im Artikel zum WordPress Backup.
- Plugins ausmisten. Jedes Plugin ist Angriffsfläche. Was nicht gebraucht wird, wird gelöscht, nicht nur deaktiviert.
- Frühwarnung. Wer deine Website betreut, sollte von kritischen Lücken erfahren, bevor Angreifer sie nutzen. Frag deinen Dienstleister, wie er das sicherstellt.
Diese Liste nennt bewusst kein bestimmtes Sicherheits-Plugin. Warum, steht weiter unten.
Praxisfall: Eine kritische PHP-Lücke auf meinem Server
Im Oktober warnte das BSI vor kritischen Lücken in PHP, der Sprache, in der WordPress läuft. Betroffen war auch der Server, auf dem meine Website läuft. Ich habe das Update von Hand eingespielt, gut drei Stunden nachdem der Fix bereitstand und damit vor der Fünf-Stunden-Marke aus dem Patchstack-Bericht. Die automatische Aktualisierung hätte erst rund 13 Stunden später gegriffen.
Danach habe ich den Server auf Spuren eines Einbruchs geprüft: hochgeladene Dateien, Konfigurationsdateien, Anmeldungen, Benutzerkonten und geplante Aufgaben. Der Befund war unauffällig. Eine Lehre für alle, die selbst Server betreuen: Nach einem Update von Systembibliotheken müssen die betroffenen Dienste neu gestartet werden, sonst läuft der alte Code weiter.
Seitdem prüft eine automatische Frühwarnung zweimal am Tag, ob es neue kritische Lücken gibt. Sie meldet sich nur bei Lücken, die ohne Anmeldung ausnutzbar sind, bereits aktiv ausgenutzt werden, einen sehr hohen Schweregrad haben oder vom BSI als besonders kritisch eingestuft werden. In den Tagen danach hat sie zwei weitere Meldungen geliefert.
Praxisfall: Der Bot, der über die Kasse kam
Bei einem Kunden war das Kontaktformular gegen Bots geschützt. Ein Bot scheiterte daran und nahm einen anderen Weg: Er schickte über die Kasse des Shops zwei Anfragen mit Namen, Adressen und Nachrichten aus Zufallsbuchstaben. Im Werbekonto wurden sie nicht als Conversion gezählt, aber sie kamen als Anfragen an.
Ich habe daraufhin auch die Kasse geschützt: ein unsichtbares Feld als Falle, eine Mindestdauer für das Ausfüllen und eine Begrenzung, wie oft hintereinander abgeschickt werden kann. Kurz darauf hat der Schutz auf der Live-Seite den ersten Versuch abgefangen, ohne dass ein Auftrag entstand. Die Lehre daraus: Jeder Weg, über den Daten auf die Website kommen, braucht denselben Schutz wie das Kontaktformular.
Reicht ein Sicherheits-Plugin?
Ein Sicherheits-Plugin ist eine sinnvolle Ergänzung, aber kein Ersatz für die Maßnahmen oben. Patchstack sieht das schärfer: Laut Bericht können sich Website-Betreiber nicht auf Plugin-Updates als Schutz verlassen, weil für fast die Hälfte der Lücken bei Veröffentlichung noch kein Fix existiert. Patchstack verteilt deshalb Schutzregeln, die eine bekannte Lücke auf betroffenen Websites abschirmen, bevor der Entwickler ein Update liefert.
Das Argument trägt, und für Websites mit vielen Plugins kann ein solcher Dienst sinnvoll sein. Er hilft aber nur gegen bekannte Lücken in Plugins, die der Anbieter abdeckt. Gegen schwache Passwörter, zu viele Administratoren, einen offenen Datei-Editor oder ein Backup, das sich nicht zurückspielen lässt, hilft er nicht. Ich sehe ein Sicherheits-Plugin deshalb als Alarmanlage. Das Fundament bleiben Updates, Zugänge und Backups.
Was du selbst prüfen kannst
- Wie viele Updates warten gerade? Schau unter Dashboard, Aktualisierungen nach. Sind Sicherheitsupdates dabei, spiel sie heute ein und teste die Seite danach.
- Wer hat Administratorrechte? Prüfe die Benutzerliste. Ehemalige Mitarbeiter und alte Dienstleister-Zugänge gehören entfernt.
- Ist die Zwei-Faktor-Anmeldung aktiv? Für alle Konten mit Zugang zum Backend.
- Ist der Datei-Editor abgeschaltet? Wenn unter Design oder Plugins ein Menüpunkt zum Bearbeiten von Dateien erscheint, ist er noch aktiv.
- Wie sieht deine Website aus, wenn man von Google kommt? Such nach deinem Firmennamen und klick auf das Ergebnis, statt die Adresse direkt einzugeben. Weiterleitungen nach einem Hack können nur auf diesem Weg greifen.
Häufige Fragen zur WordPress Sicherheit
Der WordPress-Kern ist gut gepflegt; laut Patchstack wurden 2025 nur sechs Lücken im Kern gemeldet, alle mit niedriger Priorität. Das Risiko liegt vor allem in Plugins und Themes und in Updates, die liegen bleiben. Eine gepflegte WordPress-Website mit wenigen, aktiv entwickelten Plugins lässt sich deshalb gut schützen.
Typische Zeichen sind unbekannte Seiten oder Links, Weiterleitungen auf fremde Seiten, neue Administratorkonten und ungewöhnlicher Mailversand. Weiterleitungen greifen oft nur, wenn jemand aus den Suchergebnissen kommt. Ruf deine Website deshalb auch einmal über die Google-Suche auf.
Zugänge ändern, die Seite vom Netz nehmen oder in den Wartungsmodus setzen und die Ursache suchen lassen. Ein altes Backup einzuspielen, schließt die Lücke nicht, über die der Angreifer hereingekommen ist. Sind personenbezogene Daten betroffen, prüfe die Meldepflicht nach der DSGVO: Meldungen sind unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden fällig, außer die Verletzung führt voraussichtlich nicht zu einem Risiko für die Betroffenen.
Es ist eine sinnvolle Ergänzung, vor allem bei vielen Plugins. Ersetzen kann es Updates, abgesicherte Zugänge und getestete Backups nicht. Ich sehe es als Alarmanlage. Das Fundament bleiben Updates, Zugänge und Backups.
Teilweise. Die kleinen Sicherheitsupdates des WordPress-Kerns sollten automatisch laufen. Sicherheitsupdates von Plugins und Themes spiele ich sofort ein und teste die Seite direkt danach. Alle anderen Updates gehen zuerst über eine Testkopie, weil ein automatisches Update nicht prüft, ob Formular und Tracking danach noch funktionieren.
Fazit
Bei WordPress Sicherheit zählt vor allem die Zeit zwischen dem Bekanntwerden einer Lücke und deinem Update. Wenn stark ausgenutzte Lücken im Median nach fünf Stunden angegriffen werden, ist ein monatlicher Update-Termin für Sicherheitsupdates zu spät.
Die Reihenfolge: Sicherheitsupdates sofort einspielen und testen, Zugänge absichern, Datei-Editor abschalten, Backups zurückspielen können, überflüssige Plugins löschen.
Wenn du unsicher bist, wie gut deine Website gerade geschützt ist: Im Erstgespräch schauen wir gemeinsam an, welcher nächste Schritt sich bei dir rechnet. Wie ich WordPress-Websites baue und betreue, steht auf der Seite zur WordPress-Entwicklung.
