Das PHP-Sicherheitsrelease vom Oktober 2026 war eine nützliche Erinnerung: Manche Fixes kommen nicht aus einem WordPress-Update. Liegt die Lücke in PHP selbst, ist der Fix eine neuere PHP-Version auf dem Server, und Seiten auf einem Zweig, der keine Sicherheitsfixes mehr bekommt, bekommen gar keinen Fix. Diese Anleitung ist eine Routine, die du auf jeder Kundenseite anwenden kannst, um sie ohne Überraschungen auf eine unterstützte PHP-Version zu bringen.
Warum die PHP-Version wichtiger ist, als es aussieht
Jeder PHP-Zweig bekommt nur eine begrenzte Zeit Sicherheitsfixes. Danach bleibt jede neue Lücke darin offen, egal wie sorgfältig du WordPress, Plugins und Themes aktualisierst. PHP 8.1 und älter bekommen keine offiziellen Sicherheitsfixes mehr. Sieh auf php.net/supported-versions nach den aktuellen Daten jedes Zweigs.
Es gibt einen zweiten Grund. Plugin- und Theme-Autoren lassen alte PHP-Versionen mit der Zeit fallen. Eine Seite, die auf einem alten Zweig bleibt, verliert nach und nach den Zugang zu Plugin-Updates und damit zu Sicherheitsfixes in den Plugins selbst.
Schritt 1: die PHP-Version jeder Seite erfassen
In WordPress findest du sie unter Werkzeuge → Website-Zustand → Bericht → Server. Auch dein Hosting-Panel zeigt sie an. Notiere für jede Seite die PHP-Version, die WordPress-Version, das Theme, den Page Builder, ob WooCommerce läuft und ob es eigenen Code in einem Child-Theme oder einem Must-Use-Plugin gibt.
Sortiere dann die Liste. Beginne mit den ältesten PHP-Versionen und darin mit den Seiten, die Geld verdienen oder Anfragen sammeln: Shops, Buchungsseiten und Seiten mit wichtigen Formularen.
Schritt 2: finden, was den Wechsel blockiert
Die meisten PHP-Upgrades scheitern an einem alten Plugin, einem verwaisten Theme oder einem Stück eigenem Code. Suche danach, bevor du umstellst:
- Plugins und Themes, die seit zwei Jahren oder länger nicht aktualisiert wurden. Prüfe die Zeilen „Requires PHP“ und „Tested up to“ auf ihrer Plugin-Seite.
- Alte Versionen von Page Buildern und Premium-Plugins mit abgelaufener Lizenz, sodass die Seite nie die Versionen erhielt, die neueres PHP unterstützen.
- Eigener Code in functions.php oder Must-Use-Plugins. Funktionen wie each() und create_function() wurden in PHP 8.0 entfernt, und PHP 8.2 warnt vor dynamischen Properties.
- Kompatibilitätsscanner können helfen, melden aber Fehlalarme. Sieh ihre Ausgabe als Startliste, nicht als Urteil.
Aktualisiere zuerst WordPress, Plugins und Themes, solange die Seite noch auf der aktuellen PHP-Version läuft. Neuere Plugin-Versionen unterstützen meist neueres PHP. Mach die Updates und den PHP-Wechsel an verschiedenen Tagen, damit du weißt, welche Änderung ein Problem verursacht hat.
Schritt 3: zuerst auf einer Kopie testen
Erstelle eine Staging-Kopie der Seite und stelle sie auf die Ziel-PHP-Version. Bei den meisten Hostern wählst du die PHP-Version pro Seite. Schalte WP_DEBUG_LOG auf der Kopie ein, damit Fehler in eine Logdatei statt auf den Bildschirm gehen.
Klick dich dann durch, was für diesen Kunden zählt:
- Die Startseite und die zwei oder drei meistbesuchten Seiten, auf Desktop und Mobil.
- Jedes wichtige Formular: abschicken und prüfen, ob die E-Mail ankommt.
- Bei einem Shop: in den Warenkorb, zur Kasse mit einer Testbestellung, die Kontoseite.
- Im Admin: Editor und Page Builder öffnen sich, Medien-Upload funktioniert, Einstellungsseiten laden.
Lies danach wp-content/debug.log. Fatale Fehler musst du beheben, bevor du live gehst. Deprecation-Hinweise sind Warnungen für das nächste Upgrade; schreib sie auf, sie können warten. Der Vergleich von Screenshots der wichtigsten Seiten vorher und nachher findet die Probleme, die keinen Fehler werfen, etwa einen Slider oder ein Menü, das nicht mehr angezeigt wird.
Schritt 4: die Live-Seite zu einem ruhigen Zeitpunkt umstellen
Wähle einen Zeitpunkt mit wenig Traffic. Mach direkt vor dem Wechsel ein frisches Backup von Dateien und Datenbank und notiere die aktuelle PHP-Version. Stell PHP im Hosting-Panel um, leere den Seiten-Cache und einen eventuellen Objekt-Cache und mach dieselben Prüfungen wie auf der Kopie. Lass das Fehler-Logging in eine Datei ein, zwei Tage an, damit du die Seite erwischst, die bei deiner Prüfung niemand besucht hat.
Sag dem Kunden in ein, zwei Sätzen, was du getan hast und warum. Ein PHP-Upgrade ist unsichtbar, wenn es gut läuft, und es ist gute Wartungsarbeit, von der er wissen sollte.
Schritt 5: den Weg zurück kennen
Das Zurücksetzen nach einem PHP-Upgrade ist meist einfach: Stell die Version im Hosting-Panel zurück. Deshalb hast du die alte Version notiert. Stellt sich ein Plugin als Problem heraus, hast du drei Möglichkeiten: aktualisieren, ersetzen oder kurz auf dem vorherigen unterstützten Zweig bleiben, während du es klärst. Bleib nie länger als nötig auf einem nicht unterstützten Zweig.
Wenn es dringend ist: ein Sicherheitsrelease für PHP selbst
Wird eine Lücke in PHP veröffentlicht, behebt ein WordPress-Update sie nicht. Frag deinen Hoster, ob das Patch-Release für deinen Zweig eingespielt wurde. Ein Patch innerhalb desselben Zweigs, etwa von einem 8.3-Release zum nächsten, macht selten etwas kaputt. Riskant ist der Sprung auf einen neuen Zweig, und genau darauf bereitet dich diese Anleitung vor. Seiten auf einem Zweig ohne Sicherheitsfixes planst du zuerst ein.
Update 23. Oktober 2026: ein zweites PHP-Problem mit geringerem Risiko. Zwei Tage nach dem kritischen Release veröffentlichte PHP einen informativen Hinweis zu CVE-2026-115560 in session upload progress (php.net). PHP hält eine Ausnutzung für unwahrscheinlich: Dafür sind mehrere bestimmte Einstellungen und Code gleichzeitig nötig. Einen Fix gibt es noch nicht; er kommt mit dem nächsten regulären PHP-Release. Schließ bis dahin zuerst die Updates vom 21. Oktober ab und bitte dann deinen Hoster, session.upload_progress.enabled in php.ini oder im PHP-FPM-Pool auf off zu setzen und PHP neu zu starten. Das Setzen aus WordPress oder über eine .user.ini -Datei kann bei PHP-FPM zu spät greifen.
Wie Verploy mit PHP-Upgrades umgeht
Auf Seiten mit einer alten PHP-Version zeigt der PHP-Upgrade-Check von Verploy, was den Wechsel blockiert und in welcher Reihenfolge du es behebst. Jedes Update wird geprüft, und die riskanten werden zuerst auf einer Kopie getestet. Wie das in eine vollständige Wartungsroutine passt, siehst du unter WordPress-Wartung für Agenturen.
Willst du sehen, was ein PHP-Upgrade auf deinen Seiten blockiert?
Jedes Update wird geprüft, und die riskanten werden zuerst auf einer Kopie getestet. Kostenlos starten, ohne Kreditkarte.