PHP-Sicherheitslücke in WordPress: Website prüfen und beheben

Was eine PHP-Sicherheitslücke in WordPress bedeutet

Der Begriff umfasst drei unterschiedliche Sachverhalte, die nicht auf die gleiche Weise behoben werden.

Drei Arten von Sicherheitslücken, drei Verantwortliche

Die erste Gruppe betrifft die auf dem Server installierte PHP-Version. Jeder PHP-Zweig erhält nur für einen begrenzten Zeitraum Sicherheitsupdates; danach werden entdeckte Schwachstellen nicht mehr behoben. Eine Website, die noch auf PHP 7.4 oder 8.0 läuft, nutzt eine Engine, die seit Jahren keine Patches mehr erhalten hat, und der Versionswechsel hängt vom Hosting-Anbieter oder einer einfachen Einstellung im Hosting-Panel ab. Die zweite Gruppe, bei weitem die häufigste, betrifft den PHP-Code von Erweiterungen und Themes: eine SQL-Injection in einem Formular, ein ungeprüfter Datei-Upload, eine Funktion, die ohne Authentifizierung zugänglich ist. Diese Sicherheitslücken werden wöchentlich in Schwachstellen-Datenbanken veröffentlicht, mit der Versionsnummer, in der sie behoben wurden, und werden innerhalb weniger Stunden von Bots ausgenutzt. Die Lösung ist die Aktualisierung der betroffenen Erweiterung oder deren Entfernung, falls sie nicht mehr gepflegt wird. Die dritte Gruppe umfasst Konfigurationsfehler: erlaubte Dateibearbeitung im Admin-Bereich, mögliche PHP-Ausführung im Medienordner, aktivierte Fehleranzeige im Produktivbetrieb, zu großzügige Dateirechte. Das sind keine Programmierfehler, aber sie verwandeln eine kleine Lücke in eine vollständige Übernahme. Der WordPress-Kern selbst, der regelmäßig geprüft und automatisch aktualisiert wird und nur selten Ursache einer ausgenutzten PHP-Sicherheitslücke in WordPress ist, macht nur einen geringen Teil der tatsächlichen Vorfälle aus.

PHP-Sicherheitslücke in WordPress: Was Bots wirklich ausnutzen

Die Zugriffsprotokolle eines Servers erzählen überall dieselbe Geschichte: Hunderte tägliche Anfragen aus Adressen weltweit, die gezielt nach bestimmten Dateien suchen. /wp-content/plugins/nom-extension/readme.txt um die Versionsnummer auszulesen, gefolgt von einer POST-Anfrage an die verwundbare Datei, falls die Version passt. Der Bot weiß nichts über Ihre Website; er arbeitet eine Liste von Millionen Domains mit einer Liste bekannter Sicherheitslücken ab und bleibt nur dort hängen, wo eine Antwort kommt. Bevorzugte Ziele sind Erweiterungen, die auf Millionen von Websites installiert sind: Seitenbaukästen, Kontaktformulare, Galerien, Backup-Tools, E-Commerce-Erweiterungen. Eine einzige Schwachstelle in einer davon öffnet mit einem Schlag Hunderttausende Websites, und die massenhafte Ausnutzung beginnt oft noch am Tag der Veröffentlichung des Patches, weil der Vergleich zwischen der behobenen und der vorherigen Version genau zeigt, wo angesetzt werden kann. Die Zeit zwischen der Veröffentlichung einer Sicherheitslücke und ihrer ersten automatisierten Ausnutzung wird mittlerweile in Stunden gemessen. Eine Website, die nur einmal im Monat aktualisiert wird, ist also im Schnitt zwei Wochen pro Lücke angreifbar – das reicht völlig aus. Diese Verzögerung, und nicht eine besonders raffinierte PHP-Sicherheitslücke in WordPress, erklärt die Mehrheit der kompromittierten Websites.

Erkennen, ob eine PHP-Sicherheitslücke in WordPress Ihre Website gefährdet

Drei Prüfungen, zehn Minuten, keine Entwicklerkenntnisse nötig.

PHP-Version und ihren Support prüfen

Im WordPress-Administrationsbereich zeigt das Menü Werkzeuge und dann Website-Zustand die verwendete PHP-Version an und weist darauf hin, wenn sie veraltet ist. Dieselbe Information findet sich im Panel des Hosting-Anbieters, meist unter „PHP-Konfiguration“ oder „Versionsauswahl“. Die folgende Tabelle fasst den Status der aktuellen Versionszweige zusammen. Ein Zweig am Ende seines Lebenszyklus ist nicht zwingend sofort angreifbar, aber jede neu entdeckte Schwachstelle in PHP bleibt dort dauerhaft offen. Der Wechsel zu einem unterstützten Zweig erfolgt im Hosting-Panel mit einem Klick, und in den meisten Fällen funktioniert eine aktuelle WordPress-Website ohne Anpassungen auf PHP 8.2 oder 8.3. Ausnahmen sind alte Themes und Erweiterungen, die entfernte Funktionen verwenden; man erkennt sie, indem man den Versionswechsel an einer Kopie der Website testet oder die angegebene Kompatibilität auf der offiziellen Seite prüft. Blockiert eine Erweiterung den Wechsel zu einer unterstützten PHP-Version, muss sie weichen – nicht das Update.

Verwundbare oder aufgegebene Erweiterungen erkennen

Die Liste der installierten Erweiterungen samt Versionsnummer ist die zweite Prüfung. Für jede stellen sich drei Fragen. Ist die installierte Version die aktuellste? Ein Rückstand von mehreren Versionen bei einer beliebten Erweiterung bedeutet fast immer, dass eine bekannte Sicherheitslücke offen ist. Wird die Erweiterung noch gepflegt? Ein Hinweis auf der offiziellen Seite wie „wurde nicht mit den letzten drei WordPress-Hauptversionen getestet“ oder ein letztes Update, das älter als zwei Jahre ist, deutet auf Aufgabe hin; entdeckte Sicherheitslücken werden dann nie behoben. Wird die Erweiterung überhaupt noch genutzt? Eine deaktivierte Erweiterung bleibt auf dem Server vorhanden, und ihr Code ist weiterhin direkt über die Adresse erreichbar – und damit angreifbar. Öffentliche Schwachstellen-Datenbanken wie die von Patchstack oder Wordfence ermöglichen es, den Namen einer Erweiterung zu suchen und bekannte Sicherheitslücken samt behobener Version einzusehen. Für eine einzelne Website dauert diese Kontrolle eine Viertelstunde im Monat. Für eine Agentur, die dreißig Websites verwaltet, ist es ein halber Tag – weshalb es nie manuell gemacht wird und weshalb Tools für die Verwaltung von Website-Portfolios jede installierte Version automatisch mit der Liste veröffentlichter Sicherheitslücken abgleichen und jeden Morgen die betroffenen Websites melden.

Einstellungen kontrollieren, die alles verschlimmern

Die dritte Prüfung betrifft die Konfiguration. Diese Einstellungen sind streng genommen keine Sicherheitslücken, aber sie entscheiden darüber, was ein Angreifer tun kann, sobald er eine kleine Lücke gefunden hat. Hier sind die Punkte, die in der Reihenfolge ihrer Wichtigkeit zu prüfen sind.

• PHP-Ausführung in wp-content/uploads: Ist sie möglich, wird jedes verwundbare Upload-Formular zu einer vollständigen Übernahme. Eine dreizeilige .htaccess-Datei in diesem Ordner verhindert das.
• Datei-Editor im Administrationsbereich: Ein gestohlenes Administratorkonto erlaubt dann, PHP direkt zu schreiben. Die Konstante DISALLOW_FILE_EDIT deaktiviert diese Funktion.
• Fehleranzeige: Im Produktivbetrieb muss WP_DEBUG auf false stehen, sonst geben die Meldungen Pfade und Abfragen preis.
• Dateirechte: 644 für Dateien, 755 für Ordner, niemals 777; wp-config.php kann auf 600 gesetzt werden.
• XML-RPC: deaktivieren, wenn nicht benötigt – es ist ein Angriffskanal für Brute-Force- und Verstärkungsangriffe.
• Tabellenpräfix und Kontoname: Ein Konto namens „admin“ und das Standardpräfix wp_ erleichtern automatisierte Angriffe.

Jede dieser Einstellungen lässt sich in einer Minute prüfen und in fünf Minuten korrigieren. Zusammen verwandeln sie eine kleinere Sicherheitslücke, die das Auslesen einer Tabelle ermöglicht hätte, in einen folgenlosen Vorfall.

Protokolle lesen, um zu sehen, wer an die Tür klopft

Die Zugriffsprotokolle des Servers, verfügbar im Hosting-Panel oder im Ordner logs, zeigen innerhalb weniger Minuten das, was die vorherigen Prüfungen nicht verraten: ob schon jemand versucht hat einzudringen, und auf welchem Weg. Filtern Sie die POST-Anfragen der letzten sieben Tage und suchen Sie nach solchen, die Erweiterungsdateien statt normale Seiten betreffen: admin-ajax.php mit einer unbekannten Aktion, eine direkt aufgerufene Datei in wp-content/plugins, xmlrpc.php zu Hunderten, wp-login.php von Dutzenden unterschiedlicher Adressen aus. Die Antwortcodes vervollständigen das Bild: eine Serie von 404ern zeigt einen Bot, der eine Erweiterung sucht, die Sie nicht haben, ein 200 bei einer direkt aufgerufenen Erweiterungsdatei zeigt, dass er sie gefunden hat. Notieren Sie Adressen und Daten; fällt eine verdächtige Anfrage mit einer veränderten Datei oder einem neu angelegten Konto zusammen, wurde die PHP-Sicherheitslücke in WordPress bereits ausgenutzt, und die Bereinigung hat dann Vorrang vor allem anderen. Diese Auswertung muss bei einer einzelnen Website nicht täglich erfolgen, eine monatliche Kontrolle reicht aus, aber sie wird unschätzbar wertvoll, sobald ein Symptom auftritt, weil sie den Vorfall zeitlich einordnet und die Eintrittspforte benennt. Für ein Website-Portfolio sollte sie automatisiert werden: Ein Tool, das Versuche pro Website und Tag zählt, meldet Auffälligkeiten, bevor sie zu Vorfällen werden.

Die Türen schließen – und geschlossen halten

Einmaliges Beheben bringt nichts, wenn keine Routine folgt: Jede Woche werden neue Sicherheitslücken veröffentlicht.

PHP-Sicherheitslücke in WordPress: die Update-Routine, die hält

Die wirksamste Maßnahme ist zugleich die einfachste: wöchentlich aktualisieren, und wo möglich automatisch. WordPress bietet automatische Updates für den Kern, Erweiterungen und Themes an, die einzeln je Erweiterung aktiviert werden können. Die übliche Hemmschwelle ist die Angst, die Website kaputtzumachen. Dem begegnet man mit drei Vorsichtsmaßnahmen: einer automatischen Sicherung vor jedem Update, einem kurzen Test der Startseite und eines Formulars danach, sowie einem sofortigen Rollback, falls sich etwas verändert hat. Sicherheitsupdates von Erweiterungen sind in der überwiegenden Mehrheit der Fälle klein und ändern nichts Sichtbares; es sind die als solche angekündigten Hauptversionswechsel, die einen Test an einer Kopie verdienen. Führen Sie über das Update hinaus ein Inventar: was installiert ist, warum, und seit wann. Alles, wofür es keinen Grund mehr gibt, wird entfernt, nicht nur deaktiviert. Abonnieren Sie schließlich die Warnmeldungen einer Schwachstellen-Datenbank für die von Ihnen genutzten Erweiterungen, oder verwenden Sie ein Tool, das dies für Sie übernimmt. Eine PHP-Sicherheitslücke in WordPress, die am Dienstag veröffentlicht wird, wird am Dienstagabend ausgenutzt; das Update vom Freitag kommt zu spät, das vom Dienstagmittag rechtzeitig.

PHP-Sicherheitslücke in WordPress: Was tun, wenn es noch keinen Patch gibt

Es kommt vor, dass eine Sicherheitslücke für eine aufgegebene Erweiterung veröffentlicht wird oder der Patch mehrere Tage auf sich warten lässt. Es gibt drei Optionen, von der saubersten zur vorübergehendsten. Die erste ist der Ersatz: Fast jede Erweiterung hat ein gepflegtes Äquivalent, und die Migration eines Formulars oder einer Galerie dauert eine Stunde. Die zweite ist die sofortige Deaktivierung und Entfernung, wobei man den Funktionsverlust in Kauf nimmt, bis ein Ersatz gefunden ist; eine fehlende Galerie kostet weniger als eine kompromittierte Website. Die dritte ist der virtuelle Patch, angeboten von manchen Web Application Firewalls und von Diensten wie Patchstack: eine Regel, die die bösartige Anfrage blockiert, bevor sie den verwundbaren Code erreicht, ohne die Erweiterung zu verändern. Das verschafft Zeit, ersetzt aber nicht die tatsächliche Korrektur. Prüfen Sie in jedem Fall nach der Behebung, ob die PHP-Sicherheitslücke in WordPress nicht bereits ausgenutzt wurde: kürzlich erstellte PHP-Dateien in uploads, unbekannte Administratoren, Änderungen an wp-config.php und .htaccess. Bots sind schneller als Patches, und eine behobene, aber bereits kompromittierte Website bleibt kompromittiert. Für ein Website-Portfolio ist diese tägliche Kontrolle die einzige Möglichkeit, ruhig zu schlafen: Sie meldet jeden Morgen die Websites, bei denen eine Erweiterung eine veröffentlichte Sicherheitslücke aufweist, samt der zu erreichenden Version, sowie jene, bei denen sich eine Datei grundlos verändert hat.

Häufig gestellte Fragen

Kann ein PHP-Update meine Website kaputtmachen? Selten, wenn WordPress, Theme und Erweiterungen aktuell sind. Testen Sie es an einer Kopie und nehmen Sie das Update im Hosting-Panel zurück, falls eine Fehlerseite erscheint.

Ist eine deaktivierte Erweiterung noch gefährlich? Ja. Ihr Code bleibt auf dem Server und ist weiterhin direkt erreichbar. Löschen Sie sie.

Wie erkennt man, ob eine Sicherheitslücke bereits ausgenutzt wurde? Suchen Sie nach kürzlich erstellten PHP-Dateien, unbekannten Administratoren und Änderungen an wp-config.php. Ein externer Scan ergänzt diese Prüfung, ersetzt sie aber nicht.

Reicht eine Firewall aus? Nein. Sie blockiert bekannte Angriffe, nicht die von gestern veröffentlichten. Das Update bleibt der wichtigste Schutz.