WordPress-Sicherheit: Welche Maßnahmen zuerst kommen und wogegen sie nicht helfen

Bei der WordPress-Sicherheit kommt es auf die Reihenfolge an: Zuerst halten Sie den WordPress-Kern, Plugins und Themes aktuell, löschen, was Sie nicht mehr nutzen, und sichern die Zugänge. Danach kommt ein Backup, das außerhalb des Webspace liegt und dessen Wiederherstellung Sie schon einmal ausprobiert haben. Erst dann kommen Firewall, gesperrte Schnittstellen, Sicherheits-Plugin und versteckte Login-Adresse.

Ich stütze diese Reihenfolge auf eine passive Prüfung von WordPress-Startseiten im dritten Quartal 2026 und auf zwei gehackte WordPress-Seiten, die ich 2026 untersucht habe. Jede Maßnahme hat ihre Grenze: Ein Update schließt bekannte Lücken, räumt aber keine Hintertür außerhalb der aktualisierten Dateien weg; ein Backup hilft nur, wenn es sich zurückspielen lässt; Firewall und Sicherheits-Plugin ersetzen kein Update.

Wie kommen Angreifer in eine WordPress-Seite?

Die häufigsten Angriffe laufen laut WordPress-Dokumentation über zwei Wege: speziell gebaute Anfragen, die bekannte Lücken in veralteten Plugins und veralteter Software ausnutzen, und das Erraten von Passwörtern. Die Lücken stecken fast nur in Erweiterungen: Von den 11.334 Lücken, die Patchstack für 2025 im WordPress-Umfeld zählte, lagen 91 % in Plugins, 9 % in Themes und sechs im Kern.

Die Zahlen zu den Lücken stammen aus dem Jahresbericht „State of WordPress Security in 2026“ von Patchstack, einem Hersteller, der selbst eine Schutzlösung für WordPress anbietet (Stand Februar 2026). Für Ihre Seite heißt das: Jedes Plugin und jedes Theme bringt eigene Updates mit, die jemand einspielen muss. Sobald eine Lücke samt Korrektur veröffentlicht ist, liegt laut der Härtungsanleitung von WordPress fast sicher auch offen, wie sie sich ausnutzen lässt; alte Versionen sind dadurch leichter anzugreifen.

Meine eigene Messung zeigt, wie verbreitet Rückstand ist: Bei einer passiven Prüfung von Firmen-Websites im dritten Quartal 2026 nannten WordPress-Startseiten in 127.382 Messungen ihre Version im Quelltext; 30,5 % davon lagen zwei oder mehr Versionen hinter der damals aktuellen 7.1. Das ist Rückstand, keine Aussage über offene Lücken, denn WordPress reicht Sicherheitskorrekturen auch für ältere Versionszweige nach. Gezählt habe ich Firmen-Einträge je Kreis, nicht einzelne Websites: Eine Seite, die in mehreren Kreisen eingetragen ist, zählt mehrfach. Und es zählen nur Startseiten, die ihre Version zeigen, während ein Viertel der WordPress-Seiten das nicht tut.

Auf 861 WordPress-Startseiten fand ich in derselben Prüfung fremde Inhalte, die eine Einzelprüfung des gespeicherten Abrufs als Befall eingestuft hat. Von den 731, die ihre Version nennen, lag die Hälfte (49,8 %) zwei oder mehr Versionen zurück, ein Drittel (33,0 %) lief aber auf der aktuellen 7.1. Die Zahl zeigt, was zusammentrifft, nicht, wie der Angreifer hereinkam. Ein aktueller Kern allein reicht also nicht.

„Die meisten gehackten Seiten, die auf meinem Tisch landen, hatten ein Wartungsproblem: veraltete Erweiterungen, kein Backup, kein Verantwortlicher.“

— Sascha Fix

Alle drei Punkte lassen sich beheben. Die Reihenfolge dafür richtet sich nach den Einfallswegen, und gleich danach kommt der Rückweg für den Fall, dass doch etwas passiert.

In welcher Reihenfolge sichern Sie WordPress ab?

Updates und Zugänge gehören gemeinsam an den Anfang, denn sie richten sich gegen die beiden Angriffsarten, die die WordPress-Dokumentation als häufigste nennt: bekannte Lücken in veralteter Software und Angriffe auf die Anmeldung. Danach kommt ein Backup, mit dem Sie nach einem Befall oder einem missglückten Update zurückkönnen. Firewall, Schnittstellen-Sperren, Sicherheits-Plugin, versteckte Login-Adresse und geändertes Tabellenpräfix folgen als zusätzliche Schichten.

Die Zugänge stelle ich wegen meiner eigenen Befunde gleich neben die Updates. Von den als Befall eingestuften Startseiten meiner Prüfung im dritten Quartal 2026, die ihre Version nennen, lief ein Drittel auf der damals aktuellen 7.1. Und von zwei gehackten WordPress-Seiten, die ich 2026 untersucht habe, kam der Angreifer bei einer mit gültigen Administrator-Zugangsdaten herein, ohne Sicherheitslücke; bei der anderen ließ sich der Einstieg nicht mehr belegen. Zwei Fälle zeigen nicht, wie häufig dieser Weg vorkommt. Gegen einen gültigen Zugang hilft aber kein Update. Deshalb teilen sich Updates und Zugänge den ersten Platz:

Der Ratgeber Website-Sicherheit für Unternehmen beschreibt, was für jede Unternehmenswebsite unabhängig vom System gilt, etwa SSL-Zertifikat und Notfallplan. Hier folgen die WordPress-eigenen Schritte, zuerst die Updates.

Wie halten Sie Kern, Plugins und Themes aktuell, ohne die Seite zu gefährden?

Wartungs- und Sicherheitsreleases des Kerns spielt WordPress seit Version 3.7 automatisch im Hintergrund ein, laut WordPress-Dokumentation auf den meisten Seiten. Plugins und Themes aktualisiert WordPress von sich aus nur in Sonderfällen, die das Sicherheitsteam steuert; sonst schalten Sie das je Erweiterung ein. Lassen Sie Sicherheitsupdates für Kern und kleine Erweiterungen automatisch laufen, große Plugins aktualisieren Sie von Hand.

Wie die automatischen Updates arbeiten, beschreibt die WordPress-Dokumentation zu automatischen Updates (Stand Oktober 2026). Der Patchstack-Bericht (Stand Februar 2026) zeigt, wie eng das Zeitfenster ist: Etwa die Hälfte der Lücken mit hoher Tragweite wurde binnen 24 Stunden ausgenutzt. Wer Updates liegen lässt, lässt diese Lücken offen.

Für den Kern und kleine Erweiterungen rate ich deshalb, die automatischen Updates anzulassen: Die automatische Variante wartet auf keinen Termin, und bei diesem Zeitfenster zählt jeder Tag. Und große Plugins? Für umfangreiche Erweiterungen wie WooCommerce oder einen Page Builder empfehle ich trotzdem Updates von Hand mit einem Backup direkt davor. Der erste Grund: Diese Erweiterungen greifen tief in die Seite ein, und zerbricht ein Update etwas, macht das Backup den Fehler rückgängig, sofern sich die Sicherung zurückspielen lässt.

Der zweite Grund ist die Lieferkette. Bei einer Form des Angriffs über die Lieferkette steckt der Schadcode schon im Update eines Plugins, und Seiten, die das Plugin automatisch aktualisieren, spielen die manipulierte Version ohne Zutun ein. Wer von Hand aktualisiert, spielt sie erst zu einem eigenen Termin ein; bis dahin kann die Manipulation bemerkt und die Version zurückgezogen sein. Plugin-Updates von Hand machen solche Angriffe deshalb weniger erfolgversprechend, verhindern sie aber nicht. Dieses Risiko trägt jedes Plugin, das sich automatisch aktualisiert; bei kleinen Erweiterungen wiegt aber das Zeitfenster schwerer, bei großen kommen beide Gründe zusammen.

Bekommen ältere WordPress-Versionen noch Sicherheitsupdates?

Das WordPress-Projekt unterstützt aktiv nur die neueste Version, reicht Sicherheitskorrekturen aber aus Kulanz bis zum Zweig 4.7 nach. So schloss Version 7.1.2 vom 22. September 2026 eine kritische Lücke mit möglicher Codeausführung aus der Ferne, und die Korrektur kam auch für alle älteren Zweige bis 4.7 heraus (Stand Oktober 2026).

Und ganz ohne Sicherheitsupdates? Auf einem Zweig 4.6 oder älter liefen bei meiner passiven Prüfung im dritten Quartal 2026 nur 0,5 % der 127.382 Messungen mit Versionsangabe; weitere 5,7 % lagen weit zurück auf 4.7 bis 5.9, aber noch auf Zweigen mit Sicherheitskorrekturen. Ob eine Seite die Korrektur ihres Zweigs auch eingespielt hat, sagt diese Zahl nicht.

Genau das habe ich nachgezählt. Bei meiner Prüfung im dritten Quartal 2026 zeigten zwei bis fünf Tage nach dem Sicherheitsrelease 7.1.1 noch 12,1 % von 26.096 Startseiten auf dem aktuellen Zweig 7.1 die Version davor. Auf älteren Zweigen kamen die gleichzeitig nachgereichten Korrekturen seltener an. Ich habe gemessen, was die Startseite ausliefert; zeigt ein Seiten-Cache dabei eine ältere Fassung, zählt die Seite als zurück.

„Automatische Updates sind an“ ist also eine Annahme, keine Prüfung. Sehen Sie nach jedem Sicherheitsrelease nach, ob die Korrektur angekommen ist – auf einem älteren Zweig erst recht. Was nach einer Kern-Lücke zusätzlich zu prüfen ist, wenn das Update erst spät ankam, beschreibe ich im Beitrag zur WordPress-Sicherheitslücke wp2shell.

Warum reicht es nicht, alte Plugins zu deaktivieren?

Ein deaktiviertes Plugin bleibt mit seinen Dateien auf dem Server. Die Härtungsanleitung von WordPress rät, ungenutzte Plugins zu löschen. Das gilt besonders für Erweiterungen, die das Plugin-Verzeichnis von WordPress.org geschlossen hat, etwa wegen eines Sicherheitsproblems. Solche Plugins lassen sich dort weder herunterladen noch über das Backend installieren, und den Grund nennt das Verzeichnis frühestens nach 60 Tagen und nur grob (Stand Oktober 2026). Ob eine Ihrer Erweiterungen betroffen ist, sehen Sie auf deren Seite im Plugin-Verzeichnis.

Wo überlebt eine Hintertür das Update?

Ein Update ersetzt nur die Dateien der Komponente, die es aktualisiert; bei einem Plugin oder Theme tauscht WordPress dabei den ganzen Ordner aus. Dateien an anderen Stellen und Einträge in der Datenbank bleiben liegen. Bei zwei gehackten WordPress-Seiten, die ich 2026 untersucht habe, lag die Hintertür an so einer Stelle: einmal als Datei im Ordner der Must-Use-Plugins (MU-Plugins), die WordPress ohne Aktivierung lädt, einmal als zusätzliches Administratorkonto und Schadcode in der Datenbank. Zwei Fälle zeigen, wo ich suche, nicht, wie oft es so ist. MU-Plugins erscheinen laut WordPress-Dokumentation in keiner Update-Meldung und lassen sich im Backend nicht abschalten.

Auch eine Neuinstallation ersetzt nur die WordPress-Kerndateien; Hintertüren in Plugins, Uploads oder der Datenbank bleiben. Ist der Befall schon passiert, ersetzt Aktualisieren keine Bereinigung, und auch das Löschen des betroffenen Plugins reicht nicht, wie ich am Beispiel der gehackten Elementor-Add-ons beschreibe.

Wer hat Zugang zu Ihrer WordPress-Seite?

Zugang hat jeder, der ein Administratorkonto, ein Anwendungspasswort oder die Daten für Hosting, Secure File Transfer Protocol (SFTP) oder Datenbank besitzt. Halten Sie die Zahl der Administratoren klein, schalten Sie für alle die Zwei-Faktor-Authentifizierung (2FA) ein, entfernen Sie Konten und Anwendungspasswörter, die Sie nicht zuordnen können, und vergeben Sie neue Passwörter nur von einem Gerät, das sicher nicht befallen ist.

Die Zwei-Faktor-Authentifizierung gehört nicht zum WordPress-Kern (Stand Oktober 2026). Die WordPress-Dokumentation zu Brute-Force-Angriffen empfiehlt sie trotzdem für alle Administratorkonten, über ein Plugin oder einen Identitätsanbieter. Dazu rät sie zu einem eigenen, langen Passwort oder einer Passphrase für jedes Konto und zu einem Passwort-Manager; eine Mindestlänge nennt sie nicht. Für die tägliche Arbeit empfiehlt sie außerdem Rollen mit weniger Rechten und rät davon ab, den Benutzernamen „admin“ zu verwenden.

Anwendungspasswörter gibt es seit WordPress 5.6. Mit ihnen melden sich Dienste an der REST-API an, und jedes lässt sich einzeln widerrufen, ohne dass sich das Hauptpasswort ändert.

Wie laut es an der Anmeldung zugeht, zeigt eine von zwei gehackten WordPress-Seiten, die ich 2026 untersucht habe: die, auf der der Angreifer mit gültigen Zugangsdaten hereinkam. In ihren Zugriffsprotokollen standen in rund zwei Monaten mehrere tausend Anmeldeversuche und mehrere zehntausend Anfragen an die XML-RPC-Schnittstelle. Keiner davon war nachweisbar erfolgreich. Woher die gültigen Zugangsdaten stammten, zeigt das Protokoll aber nicht.

Weil sich das nicht immer klären lässt, vergeben Sie neue Passwörter von einem Gerät, dem Sie vertrauen. Laut Härtungsanleitung von WordPress hilft keine Sicherheitsmaßnahme in WordPress oder auf dem Server, wenn auf Ihrem Rechner ein Keylogger mitschreibt. Und die Zugänge reichen über WordPress hinaus: Hosting-Konto, SFTP, Datenbank und E-Mail gehören in dieselbe Runde.

Warum schützt ein Backup nur, wenn es sich zurückspielen lässt?

Ein Backup ist erst ein Rückweg, wenn Sie es schon einmal zurückgespielt haben und es nicht auf demselben Webspace liegt wie die Seite. Solange Sie eine Sicherung nie zurückgespielt haben, ist sie ungeprüft. Und eine Sicherung auf dem Webspace der Seite kann mit ihm verloren gehen oder mit ihm befallen werden.

„Spielen Sie kein Update ohne frisches Backup ein – und probieren Sie aus, ob es sich zurückspielen lässt.“

— Sascha Fix

Für die automatischen Updates von Kern und kleinen Erweiterungen heißt das: Eine regelmäßige, automatische Sicherung außerhalb des Webspace muss schon laufen, bevor das nächste Update kommt. Vor jedem Update, das Sie von Hand einspielen, ziehen Sie zusätzlich eine frische.

Die WordPress-Dokumentation zu Backups rät zu mehreren aktuellen Sicherungen an verschiedenen Orten, etwa beim Hoster, in einem Cloud-Speicher und auf dem eigenen Rechner. Die Anleitung für WordPress-Backups zeigt, wie Sie das nach der 3-2-1-Regel einrichten. Probieren Sie die Wiederherstellung am besten in einer Staging-Umgebung aus, dann bleibt die Live-Seite unberührt.

Auch ältere Sicherungen haben ihren Wert. Laut Härtungsanleitung helfen Sicherungen von vor dem Befall beim Wiederaufbau, spätere beim Nachvollziehen, wie der Angreifer hereinkam. Ihr neuestes Backup ist deshalb nicht automatisch das sauberste: Enthält es schon die Hintertür, spielen Sie sie mit zurück. Wie Sie die richtige Sicherung finden, steht im Beitrag Website nach Hack wiederherstellen.

Was bringen Firewall, Sicherheits-Plugin und Server-Regeln zusätzlich?

Firewall, Server-Regeln und Sicherheits-Plugin filtern oder drosseln Anfragen, bevor oder während WordPress sie verarbeitet. Sie dämpfen das Dauerrauschen der Bots und halten einige Angriffe auf, ersetzen aber kein Update und entfernen keine Hintertür. Deshalb kommen sie nach Updates, Zugängen und Backup, nicht an deren Stelle.

Was unterscheidet eine Web Application Firewall von einem Sicherheits-Plugin?

Eine Web Application Firewall (WAF) läuft laut Härtungsanleitung auf dem Webserver und filtert Anfragen, bevor WordPress sie verarbeitet. Ein Sicherheits-Plugin läuft dagegen wie WordPress selbst innerhalb von PHP. Es kann Anmeldeversuche drosseln, wenn Hoster oder Content Delivery Network das nicht schon tun, verbraucht unter starkem Beschuss aber selbst Ressourcen. Die WordPress-Dokumentation empfiehlt deshalb, wo möglich, die Drosselung vor WordPress. Und ein Plugin wirkt nur, solange es läuft: Bei einer von zwei gehackten Seiten, die ich 2026 untersucht habe, war das Sicherheits-Plugin abgeschaltet, sehr wahrscheinlich vom Angreifer.

Welche Server-Regeln lohnen sich zusätzlich?

Die Schnittstelle xmlrpc.php ist laut WordPress-Dokumentation ein häufiges Ziel für Passwort-Raten. Wenn Sie sie nicht nutzen, schalten Sie sie ab; wenn Sie sie brauchen, etwa für eine App, begrenzen Sie die Anfragen. Mit dem Datei-Editor im Dashboard bearbeiten Administratoren PHP-Dateien von Plugins und Themes; laut Härtungsanleitung ist er oft das erste Werkzeug, zu dem ein Angreifer nach einer Anmeldung greift. Abschalten lässt er sich mit dieser Zeile in der wp-config.php, eingefügt vor der Zeile, die mit /* That's all, stop editing! beginnt:

define( 'DISALLOW_FILE_EDIT', true );

Danach können Administratoren im Dashboard keine PHP-Dateien mehr bearbeiten; wenn Sie die Zeile entfernen, ist der Editor wieder da. Gegen hochgeladene Schaddateien hilft das nicht, manche Angriffe stoppt es aber.

Auch was jeder von außen abrufen kann, zählt. Bei einer von zwei gehackten Seiten, die ich 2026 untersucht habe, lagen ein Fehlerprotokoll und Datenbank-Sicherungen mit Zugangsdaten im öffentlich erreichbaren Verzeichnis; ob sie abgerufen wurden, sagen die Unterlagen nicht. Die Anleitung WordPress Debug-Modus aktivieren zeigt, wie ein Fehlerprotokoll außerhalb des öffentlichen Ordners landet.

Ans Ende der Reihenfolge gehören eine versteckte Login-Adresse und ein geändertes Tabellenpräfix. Die versteckte Adresse verringert laut WordPress-Dokumentation das Rauschen, sollte aber nicht die einzige Abwehr sein. Ein anderes Präfix als das Standard-wp_ kann zumindest einige SQL-Injection-Angriffe blockieren; die Härtungsanleitung hält Verschleiern aber grundsätzlich für keine tragfähige Hauptstrategie.

Was können Sie selbst übernehmen, und wann lohnt sich eine Wartung?

Die Grundlagen der WordPress-Sicherheit schaffen Sie selbst, wenn Sie Zugang zu Hosting und Backend haben, eine Testumgebung nutzen können und nach jedem Sicherheitsrelease Zeit für eine kurze Kontrolle finden. Eine Wartung lohnt sich, wenn eine dieser Bedingungen fehlt, wenn große Plugins wie ein Shop im Einsatz sind oder wenn die Seite Kundendaten speichert.

Auch eine gepflegte WordPress-Seite kann gehackt werden, etwa über eine Lücke in einem Plugin, die zum Zeitpunkt des Angriffs noch niemand kannte. Laut dem Patchstack-Bericht (Stand Februar 2026) hatten 46 % der Lücken bei ihrer Veröffentlichung noch keine Korrektur des Entwicklers.

Dazu kommt: Einen Befall bemerken Sie im eigenen Browser kaum. Auf den 861 WordPress-Startseiten mit bestätigtem Fremdinhalt aus meiner Prüfung im dritten Quartal 2026 stand der fremde Inhalt nur bei höchstens 15,7 % sichtbar im Text. Bei 53,8 % lieferte die Seite den Fremdinhalt nur aus, wenn sich der Abruf als Suchmaschine ausgab; der Abruf als gewöhnlicher Browser bekam ihn nicht zu sehen. „Sichtbar“ ist dabei eine Obergrenze, weil die Prüfung manche Verstecke nicht erkennt.

Zur Vorsorge gehört deshalb die Frage, wer im Ernstfall reagiert. Ein Scanner, der Ihre Seite von außen prüft, findet nicht jede Hintertür; der Überblick Malware-Scanner für Websites zeigt, was die kostenlosen Werkzeuge sehen. Wie ich Updates nach einem Backup einspiele, Ihre Seite danach prüfe und regelmäßig nach Schadcode suche, beschreibe ich auf der Seite zu meiner laufenden WordPress-Wartung. Ist Ihre Seite schon befallen, führt der direkte Weg über meine Bereinigung gehackter WordPress-Seiten.