PHP 8.6 kommt: Was Website-Betreiber jetzt wissen müssen

Warum betrifft PHP 8.6 Ihre Website, und was ändert sich?

Das PHP-Projekt plant für den 19. November 2026 die Version 8.6 von PHP, der Sprache, mit der Ihr Server Webseiten für Besucher zusammenbaut (Stand November 2026). Am Erscheinungstag müssen Sie an Ihrer Website nichts umstellen, wohl aber prüfen, ob Ihre aktuelle Version Ende 2026 aus den Sicherheitsupdates fällt.

Auch wenn Sie selbst nie eine Zeile Programmcode schreiben, arbeitet PHP bei jedem Klick im Hintergrund Ihrer Website. Sobald jemand Ihre Adresse im Browser öffnet, führt der Webserver den PHP-Code Ihres Content-Management-Systems (CMS) wie WordPress, Ihres Themes und jedes aktiven Plugins aus. Der Server holt Texte oder Preise aus der Datenbank und schickt erst das fertige HTML-Dokument an den Browser. Kontaktformulare, Anmeldungen und Bestellungen im Shop laufen alle durch diese Schicht.

Diese Serversprache entwickelt sich laufend weiter. Das PHP-Team setzt die fertige Ausgabe im offiziellen Release-Plan zu PHP 8.6 für den 19. November 2026 an, dort General Availability (GA) genannt. Einzelne Termine können sich nach diesem Plan noch verschieben.

Ein solcher Versionssprung bringt neue Sprachmittel für Entwickler mit und stuft veraltete Schreibweisen als Deprecated ein. Diese Markierung legt Ihre Website nicht lahm, sondern kündigt im Fehlerprotokoll an, dass die Schreibweise in einer künftigen PHP-Version nicht mehr funktionieren wird. Laut PHP-Wiki sollen die in PHP 8.6 markierten Schreibweisen frühestens mit PHP 9 wegfallen. Echte Seitenfehler entstehen dagegen dort, wo eine Erweiterung Funktionen aufruft, die das neue PHP entfernt oder anders ausführt. Die offiziellen Upgrade-Hinweise zu PHP 8.6 führen solche inkompatiblen Änderungen in einer eigenen Liste.

Warum können Sie eine funktionierende PHP-Version trotzdem nicht jahrelang unverändert weiterlaufen lassen? Der feste Lebenszyklus setzt die Grenze. Jede PHP-Ausgabe erhält zwei Jahre lang aktive Pflege und anschließend zwei weitere Jahre Sicherheitskorrekturen. Danach ist Schluss. Wie greifbar dieser Schutz ist, zeigte sich am 21. Oktober 2026, als das PHP-Team zwei kritische Schwachstellen über gezielte Sicherheitsupdates im PHP-Kern für alle unterstützten Zweige schloss. Für abgelaufene Zweige wie PHP 8.1 erschien keine neue Version; das Sicherheitsteam stellte wegen der Schwere der Lücken nur minimale Quellcode-Korrekturen bereit.

Müssen Sie am 19. November 2026 sofort auf PHP 8.6 umstellen?

Nein. Am 19. November 2026 erscheint PHP 8.6 laut Release-Plan überhaupt erst als fertige Version; aktuell läuft noch die Testphase (Stand November 2026). Ob der neue Zweig danach für Ihre Website in Frage kommt, zeigen die Einstufung durch WordPress, das Versionsangebot Ihres Hosters und ein Vorabtest an einer Kopie.

Das PHP-Team veröffentlicht vor der fertigen Version mehrere Testkandidaten, sogenannte Release Candidates (RC). Der jüngste dieser Prüfläufe erschien am 5. November 2026 als PHP 8.6.0 RC5. Die Entwickler weisen ausdrücklich darauf hin, diese frühe Testfassung nicht auf produktiven Websites einzusetzen. Auch die PHP-Kompatibilitätstabelle im WordPress-Handbuch reicht Anfang November 2026 erst bis PHP 8.5. Der neue Zweig fehlt dort noch. Sobald die fertige Version PHP 8.6.0 veröffentlicht ist, aktualisiere ich diesen Beitrag und ergänze einen frischen Testlauf mit der Endfassung.

Ihr Hosting-Anbieter legt fest, welche PHP-Versionen auf Ihrem Webspace zur Wahl stehen. Die Hilfeseiten von STRATO und Hetzner nennen am 8. November 2026 jeweils PHP 8.5 als höchste verfügbare Version, während IONOS die PHP-Version in Managed-WordPress-Tarifen selbst verwaltet. PHP 8.6 kommt für Ihre Website deshalb erst dann in Betracht, wenn Ihr Hoster den Zweig im Kundenmenü anbietet, WordPress und Ihre eingesetzten Erweiterungen kompatibel sind und eine Kopie Ihrer Seite ohne Fehlermeldungen durchläuft.

Was bringt PHP 8.6 für Website-Betreiber im Vergleich zu PHP 8.5 und 8.4?

Für Website-Betreiber zählen bei PHP 8.6 vor allem zwei Änderungen: Drei Einstellungen für Sitzungs-Cookies sind ab Werk strenger, und PHP markiert weitere alte Schreibweisen als veraltet. Beides steht in den Upgrade-Hinweisen zur aktuellen Testfassung (Stand November 2026). Neue Sprachmittel richten sich an Programmierer, die neuen Code schreiben.

Was ändert sich bei den Sitzungs-Cookies?

Nutzt eine Anwendung die Sitzungsverwaltung von PHP, merkt sie sich damit, wer gerade auf der Seite ist. Die Daten der Sitzung liegen auf dem Server, etwa der Vermerk, dass jemand angemeldet ist. Der Browser bekommt davon nur eine zufällige Kennung, die Sitzungs-ID, in einem Cookie und schickt sie bei jedem Aufruf mit. Wer diese Kennung kennt, ist für die Anwendung derselbe Besucher. Genau dort setzen die drei neuen Standardwerte an.

Strict Mode (session.use_strict_mode steht jetzt auf 1): PHP nimmt nur noch Sitzungs-IDs an, zu denen es schon eine Sitzung gibt. Bisher startete PHP dagegen mit jeder gültig aussehenden Kennung eine Sitzung, auch mit einer ausgedachten, die etwa in einem Link steckte. Darauf baut ein Angriff namens Session Fixation: Der Angreifer schiebt seinem Opfer eine Kennung unter, die er selbst kennt, und wartet, bis sich das Opfer damit anmeldet. Danach ist er mit derselben Kennung ebenfalls angemeldet, denn für PHP ist er derselbe Besucher. Mit Strict Mode verwirft PHP eine unbekannte Kennung und vergibt eine neue, zufällige.

Merken würden Sie das deshalb vor allem bei Anwendungen, die eine Sitzungs-ID bewusst von außen übergeben. Der Änderungsvorschlag im PHP-Wiki nennt als Beispiel die Übergabe zwischen zwei Subdomains. Kommt die Kennung auf der zweiten Subdomain an, bevor die erste die Sitzung gespeichert hat, verwirft PHP sie dort und beginnt eine neue, leere Sitzung. Redis und Memcached als Sitzungsspeicher sind laut dem Vorschlag mit ihren Standard-Handlern nicht betroffen.

HttpOnly (session.cookie_httponly steht jetzt auf 1): Skripte auf der Seite können das Sitzungs-Cookie nicht mehr lesen. Der Browser schickt es weiter bei jedem Aufruf mit, nur JavaScript kommt nicht mehr an die Kennung heran. Das zählt vor allem dann, wenn es einem Angreifer gelingt, eigenes JavaScript in Ihre Seite zu schleusen (Cross-Site-Scripting): Dieses Skript kann die Sitzungs-ID dann nicht mehr auslesen und weitergeben. Bemerkbar macht sich die Änderung also nur, wenn eigener Code die Sitzungs-ID im Browser ausliest, zum Beispiel um sie in eigene Anfragen einzubauen. Dieser Code bekommt dann keinen Wert mehr.

SameSite=Lax (session.cookie_samesite steht jetzt auf Lax): Kommt ein Besucher von einer fremden Website, schickt der Browser das Sitzungs-Cookie nur noch mit, wenn er einem normalen Link folgt. Sendet eine fremde Seite ein Formular per POST an Ihre Website oder lädt sie Inhalte von dort nach, bleibt das Cookie draußen. Ein präpariertes Formular, das eine fremde Seite per POST an Ihre Website schickt, kann damit nicht mehr die Sitzung eines angemeldeten Besuchers mitbenutzen (CSRF).

Chrome und Edge behandeln Cookies ohne SameSite-Angabe laut dem Vorschlag im PHP-Wiki schon seit 2020 so. Safari tut das aber nur, wenn der Wert ausdrücklich gesetzt ist, und das übernimmt PHP 8.6 jetzt ab Werk.

Spürbar wird die Änderung dagegen an zwei Stellen, die der Vorschlag nennt: bei einer Anmeldung über einen fremden Dienst, der den Besucher per POST-Formular zurückschickt (etwa SAML-Single-Sign-on), und bei älteren Formularen auf einer anderen Domain, die ihre Daten an Ihre Seite schicken. Weil das Sitzungs-Cookie dort nicht mehr mitkommt, behandelt Ihre Anwendung den Besucher, als hätte er keine Sitzung.

Gibt Ihr Hoster oder Ihre Anwendung eigene Werte vor, etwa in der php.ini, gelten diese weiter. Die Upgrade-Hinweise nennen genau diesen Weg für Anwendungen, die das alte Verhalten brauchen: Sie setzen den jeweiligen Wert ausdrücklich, bei SameSite auf None zusammen mit session.cookie_secure.

In meinem Testlauf galten die neuen Werte bereits. In der PHP-8.6-Testumgebung vom 7. November 2026 standen Strict Mode und HttpOnly auf 1 und SameSite auf Lax, unter PHP 8.5 waren alle drei noch aus (nachgesehen am 10. November 2026). WordPress selbst nutzt die Sitzungsverwaltung von PHP nicht: Im Code von WordPress 7.1.4 kommt session_start() nur in einer Prüfung des Website-Zustands vor, die vor aktiven PHP-Sitzungen warnt. Betroffen sein können also Plugins und andere Anwendungen, die eigene Sitzungen starten. Unter PHP 8.6 RC4 blieben alle 80 angemeldeten Backend-Abrufe von WordPress mit WooCommerce und sieben weiteren Plugins angemeldet; keiner landete auf der Login-Seite.

Prüfen Sie an Ihrer Testkopie deshalb vor allem die Stellen, an denen ein fremder Dienst oder eine fremde Domain im Spiel ist: die Anmeldung über einen externen Anbieter, Formulare, die von einer anderen Adresse abgeschickt werden, und den Wechsel zwischen Subdomains.

Welche Schreibweisen markiert PHP 8.6 als veraltet?

Die Upgrade-Hinweise zu PHP 8.6 führen mehr als 30 Stellen auf, die ab dieser Version als veraltet gelten. Für Ihre Website heißt jede davon zunächst nur: Ruft ein Plugin oder eigener Code eine solche Stelle auf, läuft die Seite weiter, und PHP schreibt einen Hinweis ins Fehlerprotokoll, sofern die Protokollierung eingeschaltet ist. Ein Großteil der Liste lässt sich dabei in vier Gruppen ordnen; den Rest bilden Sonderfälle für Entwickler, etwa bei Reflection und einzelnen SPL-Klassen.

• Alte Zweitnamen: is_long(), is_integer(), is_double() und doubleval() sind andere Namen für is_int(), is_float() und floatval(). Wo alter Code sie noch nutzt, ersetzt der Entwickler den Namen.
• Einzelne Funktionen: spl_object_hash() (Nachfolger spl_object_id()), strcoll() und die Sortier-Option SORT_LOCALE_STRING (Nachfolger in der Klasse Collator), metaphone(), mysqli_get_charset() und mysqli_stmt_init() sowie die Suchfunktionen mit regulären Ausdrücken aus Mbstring (mb_ereg() und verwandte), weil die Bibliothek Oniguruma dahinter nicht mehr gepflegt wird.
• Objekte statt Listen: Wer http_build_query(), array_walk() oder mb_convert_variables() ein Objekt übergibt, bekommt einen Hinweis; dasselbe gilt für einige Kompressionsfilter. Für http_build_query(), array_walk() und die Filter nennen die Upgrade-Hinweise get_object_vars(), um das Objekt vorher umzuwandeln.
• Namen und Bauweisen im Code: eine Klassenkonstante mit dem Namen namespace; let oder is als Name für Klassen, Funktionen oder Konstanten, _ als Name einer Konstante und readonly als Funktionsname; ein return in einem finally-Block; ein Konstruktor, der einen Wert zurückgibt; ein drittes Argument für define(); is_a() und is_subclass_of() mit einem Klassennamen als Text, obwohl der Aufruf Text ausschließt; mehr als 16 Filter in einer php://filter-Adresse, ohne dass der Code dafür eine eigene Obergrenze festlegt.

Für die Aufrufe von is_a() und is_subclass_of() mit Text steht im PHP-Wiki ausdrücklich, dass sie in PHP 9 zum Fehler werden sollen. Denn ein solcher Aufruf liefert laut Wiki ohnehin immer das Ergebnis false und deutet deshalb auf einen Fehler im Code hin. Genau diese beiden Hinweise machten in meinem Testlauf 70 der 129 Zeilen im Protokoll aus.

Was zeigt der Testlauf mit WordPress und verbreiteten Plugins unter PHP 8.6?

In meiner Container-Testreihe im November 2026 luden alle geprüften Seiten einer WordPress-Installation mit acht verbreiteten Erweiterungen unter der Vorabversion PHP 8.6 RC4 ohne Fehlertext. Das Fehlerprotokoll füllte sich im Hintergrund dennoch deutlich stärker als unter PHP 8.5, weil vier Plugins noch Code nutzen, den PHP 8.6 als veraltet markiert.

Ich habe für diesen Praxistest eine frische WordPress-Installation mit dem Theme Astra und acht verbreiteten Plugins aufgesetzt. Mit dabei waren WooCommerce, Elementor, Yoast SEO, Contact Form 7, Wordfence, UpdraftPlus, Advanced Custom Fields und WP Mail SMTP. In isolierten Containern luden im November 2026 unter PHP 8.6 RC4 alle 96 geprüften Seitenabrufe in Frontend und Backend vor und nach einem Kern-Update fehlerfrei. Mein Beitrag zum Vorab-Testlauf für das WordPress-7.2-Update beleuchtet denselben Prüfaufbau aus Sicht des CMS.

Das Protokoll füllt sich trotzdem. Unter PHP 8.6 RC4 standen nach dem Update 129 Deprecated-Einträge darin, im selben Aufbau unter PHP 8.5 waren es 49. Diese 49 Zeilen stehen unter beiden Versionen gleich im Protokoll. Den Zuwachs um 80 Zeilen lösen genau drei Schreibweisen aus, die PHP 8.6 neu als veraltet markiert:

• 70 Zeilen von Yoast SEO (57) und WooCommerce (13): is_subclass_of() und is_a() mit einem Klassennamen als Text, obwohl der Aufruf Text ausschließt.
• 9 Zeilen von Elementor (8) und Wordfence (1): eine Klassenkonstante mit dem Namen namespace. PHP will das Wort laut Wiki für eine künftige Schreibweise reservieren.
• 1 Zeile von Wordfence: ein Konstruktor, der einen Wert zurückgibt.

Jede Zeile ist ein Eintrag im Protokoll; derselbe Yoast-Hinweis stand 57-mal darin. Aus dem WordPress-Kern selbst kam kein einziger dieser Hinweise. Ein schwerer Fehler (Fatal Error) trat in keinem Durchgang auf. Solange die Fehlerausgabe auf der Live-Seite abgeschaltet ist, sehen Besucher solche Einträge im Browser nicht. An Ihrer Testkopie schalten Sie das Protokoll in WordPress mit WP_DEBUG und WP_DEBUG_LOG in der wp-config.php ein, mehr dazu im Lexikon unter Debug-Modus. Steht dort ein Plugin, prüfen Sie, ob es ein Update gibt, oder melden Sie den Hinweis dem Hersteller.

Welche PHP-Version sollten Sie jetzt einstellen?

Stellen Sie eine produktive Website heute auf PHP 8.4 oder PHP 8.5 um, sofern Ihr Hoster diese Versionen anbietet und Ihre Erweiterungen mitspielen (Stand November 2026). Handlungsbedarf besteht vor allem bei älteren Zweigen bis einschließlich PHP 8.2, weil dort spätestens am 31. Dezember 2026 die Sicherheitsupdates enden.

Wer auf einem abgelaufenen PHP-Zweig bleibt, lässt neu entdeckte Lücken offen oder zahlt beim Anbieter monatliche Aufschläge, die meine Übersicht zum PHP Extended Support beim Hoster einordnet. Laut der Übersicht der unterstützten Versionen auf php.net erhält PHP 8.1 schon seit Ende 2025 keine Sicherheitskorrekturen mehr, und bei PHP 8.2 endet diese Phase am 31. Dezember 2026. Gehen Sie beim Wechsel heute deshalb direkt auf eine aktiv gepflegte Ausgabe. PHP 8.3 nehme ich nur als kurzen Zwischenschritt, falls ein einzelnes Plugin unter PHP 8.4 noch streikt.

Sie sehen in WordPress unter Werkzeuge → Website-Zustand → Bericht → Server ohne Umweg über das Hoster-Login, welche Version auf Ihrem Webspace gerade arbeitet. Die Anleitung PHP-Version beim Hoster umstellen zeigt Ihnen anschließend Schritt für Schritt, wo Sie den Schalter im Kundenmenü von IONOS, STRATO, All-Inkl oder Hetzner finden.

Wie bereiten Sie Ihre Website auf PHP 8.6 vor?

Bereiten Sie jeden PHP-Wechsel in vier ruhigen Schritten vor, bevor Sie die Live-Seite umschalten. Legen Sie zuerst eine Sicherung außerhalb Ihres Webspace an, aktualisieren Sie CMS und Plugins, testen Sie die neue PHP-Version an einer Kopie und prüfen Sie danach Formulare, Warenkorb sowie Fehlerprotokoll.

Am Anfang steht immer ein frisches Backup aus Dateien und Datenbank außerhalb Ihres eigenen Webspace. Kombinieren Sie dafür die automatische Hoster-Sicherung mit einem eigenen Backup-Plugin und probieren Sie einmal aus, ob sich die Sicherung wirklich zurückspielen lässt. Danach aktualisieren Sie Erweiterungen und Theme, weil Hersteller ihre Anpassungen für neuere PHP-Zweige über laufende Updates ausliefern. Automatische Sicherheitsupdates helfen beim WordPress-Kern und kleinen Plugins. Große Bausteine wie WooCommerce oder Page Builder aktualisiere ich dagegen einzeln von Hand direkt nach einer Sicherung, wie im Leitfaden WordPress-PHP-Version aktualisieren beschrieben.

Schalten Sie die neue PHP-Version anschließend zuerst in einer Staging-Umgebung scharf, also an einer geschützten Kopie Ihrer Website. Schicken Sie dort selbst eine Testanfrage über Ihr Kontaktformular oder eine Probebestellung im Shop ab. Läuft die Kopie rund, folgt die Live-Seite. Notieren Sie vorher die bisherige PHP-Version. Falls auf der Live-Seite dennoch ein Fehler auftritt, stellen Sie im Kundenmenü sofort wieder die notierte Version ein, sofern Ihr Hoster sie noch anbietet. Bleibt der Bildschirm leer, hilft mein Ratgeber Weiße Seite in WordPress beheben weiter.

PHP-Umstellung selbst machen oder modernisieren lassen?

Sie erledigen die PHP-Umstellung gut selbst, wenn Ihre Website laufend gepflegt wurde, Sie ins Kundenmenü Ihres Hosters kommen, eine getestete Sicherung bereitliegt und kein alter Eigencode im Theme steckt. Fehlen über mehrere Jahre Updates oder laufen verwaiste Plugins mit, übernehme ich Prüfung und Umstellung zuerst in einer Kopie.

Auf einer gepflegten Standard-Website mit überschaubaren Erweiterungen reichen im Kundenmenü ein paar Klicks, sobald Sicherung und Testkopie stehen. Anders sieht es aus, wenn niemand genau weiß, welche Anpassungen im Child-Theme stecken, keine Testkopie bereitsteht oder ein Shop keinen Ausfall verträgt.

Wenn an Ihrer WordPress-Website lediglich PHP veraltet ist, prüfe ich vorab, ob Theme und Plugins mit der neuen Version laufen. Anschließend stelle ich zuerst in einer Kopie auf PHP 8.4 oder 8.5 um und behebe Fehler dort. Ich erledige diese PHP-Umstellung zum Festpreis inklusive Nachbetreuung für 249 € zzgl. 19 % USt. Liegt auch WordPress selbst weit zurück oder müssen verwaiste Plugins ersetzt werden, kostet die vollständige Modernisierung ab 690 € zzgl. 19 % USt. Mein Beitrag WordPress lange nicht aktualisiert beschreibt typische Warnsignale dafür.

Arbeitet hinter Ihrer Domain kein Redaktionssystem, sondern eine individuell programmierte PHP-Anwendung, gehört die Anpassung nicht in ein Standard-Paket – diesen Fall deckt meine individuelle Softwareentwicklung ab. Und manchmal zeigt der Blick unter die Haube, dass auch eine reine Modernisierung nicht mehr weit genug greift:

„Ein Relaunch lohnt sich, wenn die Substanz nicht mehr trägt. Das ist der Fall, wenn Ihre Seite auf einem System läuft, für das es keine Sicherheitsupdates mehr gibt; wenn sie auf dem Smartphone nicht bedienbar ist und das Nachbessern teurer würde als der Neubau; oder wenn sich das Geschäft so verändert hat, dass die Struktur nicht mehr passt.“

— Sascha Fix

Ich schaue mir Ihre Website in einer kostenlosen Bestandsaufnahme vorab unverbindlich an und sage Ihnen klar, ob die einfache PHP-Umstellung genügt oder welcher Weg für Ihre Seite trägt.