Viele WordPress-Websites laufen auf PHP-Versionen, die längst keine Sicherheitsupdates mehr erhalten. Security-Plugins können diese Lücke nicht schließen, weil sie oberhalb von PHP arbeiten. Was ein WordPress PHP Update wirklich bringt und wie Sie es vorbereiten.

Sicherheit beginnt unterhalb der Plugin-Ebene

Ein WordPress PHP Update ist die wirksamste einzelne Sicherheitsmaßnahme, die Website-Verantwortliche selbst anstoßen können. Veraltetes PHP bedeutet: bekannte Schwachstellen in der Sprache, auf der WordPress läuft, bleiben offen. Kein Security-Plugin kann das kompensieren, weil Plugins oberhalb von PHP arbeiten und eine Lücke in der Sprachebene selbst nicht erreichen.

Dieser Artikel zeigt, wie Sie Ihre aktuelle PHP-Version prüfen, welche Risiken eine ungepatchte Version mit sich bringt und wie Sie ein Update vorbereiten, ohne den laufenden Betrieb zu gefährden. Dabei folgt jeder Abschnitt einem klaren Handlungsprinzip: erst den eigenen Stand ermitteln, dann das Risiko einordnen, dann in einer Staging-Umgebung testen und schließlich mit vorbereiteten Fragen an den Hoster das Update anstoßen. So bleibt das Thema auch ohne technischen Hintergrund umsetzbar.

Welche PHP-Version läuft auf meiner Website, und bekommt sie noch Sicherheitsupdates?

Die PHP-Version Ihrer WordPress-Website steht im Dashboard unter Werkzeuge → Website-Zustand → Bericht, Abschnitt Server. Dort zeigt WordPress die aktuell vom Hosting-Server verwendete PHP-Version an, ohne dass Sie dafür ein zusätzliches Plugin installieren oder sich per SSH einloggen müssen.

Ob diese Version noch Sicherheitsupdates erhält, ist eine andere Frage. PHP-Versionen durchlaufen nach ihrer Veröffentlichung zwei Phasen: eine Phase mit aktiven Fehlerkorrekturen und danach eine Phase, in der nur noch Sicherheitslücken gepatcht werden. Nach Ablauf dieser zweiten Phase endet der offizielle Support vollständig. Die abgerufenen Quellen für diesen Artikel liefern keine aktuelle, datierte Liste der derzeit noch unterstützten PHP-Versionen. Für den verbindlichen Stand verweist das PHP-Projekt selbst auf seiner Website eine Übersicht der unterstützten Versionen mit genauen Enddaten (php.net/supported-versions).

Woran Sie erkennen, dass Ihre Version nicht mehr gepflegt wird:

• WordPress-Dashboard-Hinweis: WordPress selbst zeigt im Website-Zustand eine Warnung, wenn die eingesetzte PHP-Version als veraltet gilt. Steht dort eine orangefarbene oder rote Meldung zur PHP-Version, ist das ein klares Signal.
• Abgleich mit der offiziellen PHP-Seite: Vergleichen Sie die unter Werkzeuge → Website-Zustand angezeigte Versionsnummer mit der Übersicht auf php.net/supported-versions. Taucht Ihre Version dort nicht mehr auf, erhält sie keine Patches mehr.
• Hoster-Mitteilungen: Viele Hosting-Anbieter informieren per E-Mail, wenn eine eingesetzte PHP-Version das Support-Ende erreicht. Solche Mails landen allerdings oft ungelesen im Postfach.

Ist die eigene Version aus dem Support gefallen, bedeutet das nicht, dass die Website sofort gehackt wird. Es bedeutet, dass neu entdeckte Schwachstellen in dieser PHP-Version von niemandem mehr offiziell geschlossen werden. Jeder Tag ohne Patch vergrößert die Angriffsfläche, auf der die gesamte WordPress-Installation aufsitzt.

Was passiert, wenn PHP keine Sicherheitspatches mehr bekommt

Bekannte Schwachstellen in einer nicht mehr gepatchten PHP-Version bleiben offen, und Angreifer nutzen genau das aus. Sobald der offizielle Sicherheitssupport für eine PHP-Version endet, veröffentlicht niemand mehr Korrekturen für neu entdeckte Lücken in dieser Version. Die Schwachstellen sind dokumentiert, öffentlich einsehbar und damit für jeden nutzbar, der danach sucht.

Das Angriffsmuster ist dabei selten ein gezielter Einbruch durch einen Menschen. Verbreitet sind automatisierte Scans, die große Mengen von Websites auf bekannte Merkmale prüfen: welche PHP-Version antwortet, welche Server-Header zurückkommen, welche Fehlermeldungen die Installation preisgibt. Findet ein solcher Scan eine ungepatchte Version, kann der nächste Schritt automatisch folgen, etwa das Einschleusen von Schadcode über eine Lücke in der Sprachebene selbst, unterhalb von WordPress, unterhalb jedes Plugins.

Der Unterschied zu einer Plugin-Schwachstelle ist dabei wesentlich: Eine Lücke in einem Plugin betrifft die Anwendungsschicht. Eine Lücke in PHP betrifft die Laufzeitumgebung, auf der WordPress und jede seiner Erweiterungen ausgeführt werden. Wer PHP kontrolliert, kontrolliert alles, was darauf läuft.

Wie der vorherige Abschnitt gezeigt hat, lässt sich der Support-Status der eigenen Version mit wenigen Klicks prüfen. Wer dabei feststellt, dass die eingesetzte Version nicht mehr auf php.net/supported-versions gelistet ist, steht vor einer konkreten Situation: Jede künftig bekannt werdende Schwachstelle in dieser Version wird nicht mehr offiziell behoben. Die Angriffsfläche wächst mit jeder neuen Entdeckung, während die Verteidigung auf dem Stand des letzten Patches stehen bleibt.

Dieses Risiko bleibt nicht abstrakt. Die abgerufenen Quellen zu diesem Artikel zeigen, dass WordPress-Sicherheit in der Community aktiv diskutiert wird, unter anderem im Kontext zunehmend KI-gestützter Angriffsmethoden, die das Tempo weiter erhöhen (WP Tavern, Podcast #232 mit Aaron D. Campbell, September 2026). Automatisierte Angriffe auf bekannte Schwachstellen gehören zum Alltag des Webbetriebs. Eine ungepatchte PHP-Version macht eine WordPress-Installation dabei nicht zu einem schwierigen Ziel, sondern zu einem einfachen.

Warum ein Security-Plugin die PHP-Lücke nicht schließen kann

Security-Plugins arbeiten auf der Anwendungsebene, also oberhalb von PHP. Eine Schwachstelle in der Sprache selbst können sie weder erkennen noch schließen. Das liegt nicht an der Plugin-Qualität, sondern an einer architektonischen Grenze.

Ein Vergleich macht das greifbar: PHP ist das Fundament, auf dem WordPress steht. Ein Security-Plugin ist ein Türsteher im Gebäude. Der Türsteher kontrolliert, wer durch die Tür kommt, prüft Anfragen, blockiert verdächtige Muster. Aber wenn das Fundament einen Riss hat, hilft kein Türsteher. Der Angriff kommt nicht durch die Tür, sondern durch den Boden.

Genau das passiert bei einer ungepatchten PHP-Version. Wie der vorherige Abschnitt beschrieben hat, betreffen solche Lücken die Laufzeitumgebung unterhalb jeder Anwendungsschicht. Ein Security-Plugin läuft selbst auf dieser Schicht und kann daher weder den PHP-Interpreter reparieren noch Speicherfehler in der Laufzeitumgebung beheben oder eine Schwachstelle in einer Standardfunktion der Sprache patchen.

Das bedeutet nicht, dass Security-Plugins überflüssig sind. Sie erfüllen eine andere Aufgabe: Schutz auf der Anwendungsebene, etwa gegen Brute-Force-Angriffe auf das Login, gegen bekannte Plugin-Schwachstellen oder gegen manipulierte Datei-Uploads. Diese Schutzschicht hat ihren Wert. Aber sie setzt voraus, dass die darunterliegende Ebene selbst gepflegt ist. Ein Plugin ergänzt ein aktuelles PHP. Es ersetzt keines.

Wer sich auf ein Security-Plugin verlässt und gleichzeitig eine PHP-Version ohne Sicherheitssupport betreibt, schützt die oberen Stockwerke eines Gebäudes, dessen Fundament offen liegt. Die Priorität ist damit klar: zuerst die PHP-Version auf einen Stand bringen, der noch Sicherheitspatches erhält. Danach lohnt sich das Gespräch darüber, welche zusätzlichen Schutzmaßnahmen auf Anwendungsebene sinnvoll sind.

WordPress PHP Update vorbereiten: Was vorher zu prüfen ist

Bevor ein PHP-Update eingespielt wird, sind zwei Dinge zu tun: ein vollständiges Backup der Website anlegen und danach prüfen, ob Plugins, Theme und eigener Code mit der Ziel-PHP-Version kompatibel sind. Wer diesen Check überspringt, riskiert, dass die Website nach dem Update Fehler wirft oder im schlimmsten Fall nicht mehr erreichbar ist.

Die Prüfung folgt einer klaren Reihenfolge:

• Backup anlegen: Datenbank und Dateien sichern, bevor irgendetwas geändert wird. Das Backup muss vollständig und wiederherstellbar sein, nicht nur ein Datenbankexport. Viele Hoster bieten Backup-Funktionen im Kundenbereich an; alternativ erledigen Backup-Plugins diese Aufgabe.
• Plugin-Kompatibilität prüfen: Auf der WordPress.org-Seite jedes installierten Plugins steht, welche PHP-Version es mindestens voraussetzt und bis zu welcher Version es getestet wurde. Plugins, die seit über einem Jahr kein Update erhalten haben oder deren Entwickler das Projekt aufgegeben haben, verdienen besondere Aufmerksamkeit. Ein Plugin ohne aktive Pflege wird mit einer neueren PHP-Version wahrscheinlich nicht getestet worden sein.
• Theme-Kompatibilität prüfen: Das aktive Theme muss die Ziel-PHP-Version unterstützen. Bei kommerziellen Themes steht die Information in der Regel im Changelog oder in der Dokumentation des Anbieters. Bei Themes aus dem WordPress.org-Verzeichnis gibt die Plugin-/Theme-Seite selbst Hinweise. Fehlt eine Angabe, lohnt eine direkte Nachfrage beim Anbieter, bevor das Update läuft.
• Child-Themes und eigenen Code prüfen: Wer ein Child-Theme nutzt oder eigene PHP-Snippets in der functions.php pflegt, muss diesen Code auf Funktionen prüfen, die in der Zielversion als veraltet (deprecated) markiert oder entfernt wurden. PHP gibt solche Änderungen in seinen Migrationsanleitungen bekannt. Typische Stolperstellen sind geänderte Standardwerte bei Funktionsparametern oder entfernte Funktionen, die in älteren Versionen noch liefen.

Ein Punkt wird dabei oft übersehen: Nicht das Update selbst verursacht Probleme, sondern Code, der stillschweigend auf Verhalten einer alten PHP-Version angewiesen war. Die Vorbereitung ist deshalb kein optionaler Zwischenschritt, sondern der Teil der Arbeit, der darüber entscheidet, ob das Update glatt läuft oder die Website offline geht.

Staging-Umgebung: Das Update gefahrlos testen

Eine Staging-Umgebung ist eine vollständige Kopie der eigenen Website, auf der sich das PHP-Update testen lässt, ohne dass die live erreichbare Seite davon betroffen ist. Funktioniert nach dem Update alles wie erwartet, wird dieselbe Änderung auf der echten Website durchgeführt. Geht etwas schief, bleibt der laufende Betrieb unberührt.

Ob eine Staging-Umgebung zur Verfügung steht, hängt vom Hosting-Anbieter ab. Zwei Wege führen zum Ziel:

• Der Hoster bietet Staging an: Viele Hosting-Pakete im mittleren Preissegment enthalten eine Staging-Funktion, oft erreichbar über den Kundenbereich oder das Hosting-Dashboard unter Bezeichnungen wie „Staging“, „Testumgebung“ oder „Clone“. Ein Klick erstellt eine Kopie der Website auf einer separaten Adresse. Dort lässt sich die PHP-Version umstellen, ohne dass Besucher der echten Website etwas davon merken.
• Der Hoster bietet kein Staging an: Wer keine Staging-Funktion im Hosting-Paket findet, kann die Website lokal auf dem eigenen Rechner testen. Programme wie Local (von WP Engine) oder DevKinsta erstellen eine WordPress-Umgebung auf dem Desktop, in die sich ein Backup der eigenen Website importieren lässt. Die PHP-Version lässt sich dort frei wählen. Das erfordert keinen Server-Zugang und keine Kommandozeile, nur die Installation der Software und ein aktuelles Backup.

Steht die Kopie, folgt der eigentliche Test: die PHP-Version auf den gewünschten Stand umstellen und die Website systematisch durchklicken. Dabei zählt nicht die Startseite allein.

• Kontaktformulare: Ein Formular absenden und prüfen, ob die Bestätigungsmail ankommt.
• Shop-Funktionen: Falls ein WooCommerce-Shop läuft, einen Testbestellvorgang bis zum letzten Schritt durchspielen.
• Individuelle Seitenfunktionen: Slider, Filterfunktionen, Login-Bereiche, eingebettete Kalender oder Buchungssysteme einzeln aufrufen. Gerade solche Funktionen hängen oft an Plugins, die wie im vorherigen Abschnitt beschrieben auf Kompatibilität geprüft werden sollten.
• PHP-Fehlermeldungen: Im Staging kann man die WordPress-Debug-Funktion aktivieren (WP_DEBUG auf true in der wp-config.php), um Warnungen sichtbar zu machen, die auf der Live-Website unterdrückt werden. Eine Warnung ist noch kein Fehler, zeigt aber, welcher Code Anpassung braucht.

Erst wenn der Staging-Test keine Fehler zeigt, steht das Update auf der Live-Website an. Das Backup aus der Vorbereitung bleibt als Rückversicherung bestehen.

Die richtigen Fragen an Hoster oder Agentur

Vier konkrete Fragen reichen aus, um die Gesprächsgrundlage mit dem eigenen Hoster oder der betreuenden Agentur zu schaffen, bevor ein PHP-Update ansteht.

• „Welche PHP-Versionen sind auf meinem Tarif verfügbar?“ Nicht jeder Hosting-Tarif bietet die jeweils aktuelle PHP-Version an. Manche Anbieter stellen neue Versionen erst Wochen nach deren Veröffentlichung bereit, andere gar nicht auf älteren Tarifmodellen. Die Antwort zeigt, ob ein Update im bestehenden Vertrag überhaupt möglich ist oder ob ein Tarifwechsel nötig wird.
• „Kann ich die PHP-Version selbst umschalten, oder muss das der Support erledigen?“ Bei vielen Hostern lässt sich die PHP-Version im Kundenbereich mit einem Klick ändern. Bei anderen ist dafür ein Support-Ticket nötig, das Stunden oder Tage dauern kann. Wer das vorher weiß, plant den Zeitpunkt des Updates besser.
• „Gibt es eine Staging-Möglichkeit auf meinem Tarif?“ Wie der vorherige Abschnitt gezeigt hat, ist eine Staging-Umgebung der sicherste Weg, ein PHP-Update vorab zu testen. Ob der eigene Tarif das bietet, ist keine Selbstverständlichkeit. Falls nicht, lohnt die Nachfrage, ob der Anbieter ein Upgrade mit Staging-Funktion anbietet oder ob eine lokale Testumgebung die bessere Alternative ist.
• „Wird bei Problemen nach dem Wechsel auf die vorherige PHP-Version zurückgesetzt?“ Im Idealfall lässt sich die PHP-Version genauso schnell zurückschalten wie umstellen. Manche Anbieter tun das auf Zuruf, andere benötigen dafür ein manuelles Eingreifen durch den Support. Wer diese Rückfalloption vorher geklärt hat, geht mit weniger Risiko in das Update.

Eine fünfte Frage ist je nach Situation sinnvoll: „Informieren Sie mich aktiv, wenn eine PHP-Version das Support-Ende erreicht?“ Wie im Abschnitt zur Versionsprüfung erwähnt, verschicken nicht alle Hoster solche Hinweise automatisch. Wer sich darauf verlässt, ohne es geprüft zu haben, erfährt im Zweifel erst von einer veralteten Version, wenn WordPress selbst im Dashboard warnt.

Alle fünf Fragen lassen sich wörtlich so an den Hoster oder die Agentur schicken. Die Antworten zusammen ergeben ein klares Bild davon, wie aufwendig das Update im eigenen Fall wird und ob der aktuelle Anbieter den Prozess ausreichend unterstützt.

Fazit

Die PHP-Version aktuell zu halten ist keine technische Nebensache, sondern die wirksamste Sicherheitsentscheidung, die Website-Verantwortliche selbst treffen können. Kein Plugin kann eine Lücke im Fundament schließen, auf dem die gesamte WordPress-Installation läuft. Der eine nächste Schritt: Öffnen Sie jetzt Werkzeuge → Website-Zustand → Bericht in Ihrem WordPress-Dashboard und prüfen Sie die dort angezeigte PHP-Version. Steht sie nicht mehr auf php.net/supported-versions, ist das der Anlass, heute das Update anzugehen.