PHP 8.6: Erscheinungstermin und was Sie vor dem Umstieg prüfen sollten

Warten Sie für PHP2Shell nicht auf 8.6

PHP 8.6 ist noch nicht erschienen. Der neueste Build ist ein Release Candidate, und laut PHP-Projekt sind solche Builds zum Testen gedacht, nicht für den Produktivbetrieb.

Die Releases mit Fix, die Sie heute installieren können, sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für die meisten Websites ist 8.4 der richtige Schritt. Siehe Welche Version. Die Advisories nennen als betroffen nur die Zweige 8.2 bis 8.5. Ob die Release Candidates von 8.6 die PHP2Shell-Fixes enthalten, haben wir nicht geprüft. Einen Release Candidate auf einer Live-Website zu betreiben, um das herauszufinden, sollten Sie lassen.

Erscheinungstermin

Die Release-Seite des PHP-Projekts für 8.6 auf wiki.php.net, zuletzt bearbeitet am 21.10.2026, nennt die allgemeine Verfügbarkeit (GA) am 19.11.2026. Das deckt sich mit dem Datum in unseren Notizen. Es ist ein geplanter Termin. Endgültig ist erst, was php.net als Release ankündigt.

Laut Wiki kam der weiche Feature Freeze mit Beta 1 am 13. August und der harte am 22. September. Seitdem brauchen neue Features die Zustimmung der Release Manager. Der Funktionsumfang steht damit im Wesentlichen fest. Die Seite der Vorabversionen auf php.net führt 8.6.0RC4 mit Datum 21.10.2026.

Supportdaten für 8.6 sind noch nicht veröffentlicht. Die Seite der unterstützten Versionen führt 8.6 nicht auf. Die erklärte Regel des Projekts sind zwei Jahre aktiver Support und danach zwei weitere Jahre nur mit Sicherheitsupdates. Konkrete Daten für 8.6 nennen wir erst, wenn das Projekt sie nennt.

Was feststeht

Der RFC-Index im Wiki führt diese Punkte für PHP 8.6 unter „Implemented“. Die Liste ist eine Auswahl.

• Partial Function Application.
• Standardwerte für readonly-Properties.
• Eine Funktion clamp().
• Eine Klasse Duration.
• Eine Polling-API.
• Verbesserte Fehlerbehandlung bei Streams.
• Ein Enum SortDirection.
• #[\Override] für Klassenkonstanten.
• Debuggbare Enums.
• Sichere Standardwerte für die Session-Konfiguration.
• Seitenvorschub (Form Feed) in den trim()-Funktionen.
• Das Ende der mbregex-Unterstützung, weil Oniguruma nicht mehr gepflegt wird.
• Die Deprecation von Rückgabewerten aus __construct() und __destruct().

Was nur vorgeschlagen oder in Diskussion ist, führen wir nicht auf. Der RFC-Index zeigt außerdem einen angenommenen RFC „Minimum supported versions for PHP 8.6“. Dessen Text haben wir nicht gelesen.

Was Sie vor dem Umstieg prüfen sollten

Diese Änderungen stammen aus der Datei UPGRADING im Zweig PHP-8.6 von php-src. Eine Datei auf einem Zweig kann sich bis zur GA noch ändern. Prüfen Sie sie beim Release erneut.

Verhaltensänderungen, die eine Website brechen können

• Neue Session-Standardwerte: session.use_strict_mode=1, session.cookie_httponly=1 und session.cookie_samesite="Lax". Testen Sie Logins, Warenkörbe und alle Abläufe über mehrere Websites hinweg, etwa Rücksprünge vom Zahlungsanbieter und Single Sign-on.
• trim(), ltrim() und rtrim() entfernen jetzt standardmäßig auch den Seitenvorschub (\f).
• Strengere Eingabeprüfungen. Viele Funktionen lehnen NUL-Bytes jetzt mit einem Fehler ab, darunter getenv(), putenv(), parse_str(), proc_open() und die Dateistatus-Funktionen wie file_exists() und is_file(). Suchen Sie nach Code, der ungefilterte Benutzereingaben an diese Funktionen übergibt.
• preg_grep() gibt bei einem PCRE-Fehler false zurück statt eines unvollständigen Arrays.
• Ein harter Out-of-Memory-Fehler ruft jetzt abort() auf, und der Prozess endet mit Exit-Code 134. Prüfen Sie Monitoring und Prozess-Supervisoren, die auf Exit-Codes reagieren.

Deprecations

• return innerhalb von finally.
• Ein drittes Argument für define().
• Rückgabewerte aus __construct() und __destruct().
• Die Aliase is_double(), is_long(), is_integer() und doubleval().
• spl_object_hash().
• Mbregex.
• Session-Handler ohne create_sid() und validateId().

Schritte

1. Warten Sie die GA ab und danach, bis Ihr Hoster oder Ihre Distribution den neuen Zweig anbietet.
2. Prüfen Sie Ihr CMS. Laut WordPress-Handbuch kam die Unterstützung für PHP 8.5 mit WordPress 6.9. Sehen Sie nach der GA im Handbuch nach, was für 8.6 und Ihre WordPress-Version gilt.
3. Scannen Sie auf Staging. PHP 8.2 auf 8.4 zeigt die Befehle für PHPCompatibility. Setzen Sie testVersion auf Ihre Zielversion, sobald Ihre PHPCompatibility-Version sie kennt.
4. Testen Sie nur auf Staging. Ein Release Candidate gehört nie in die Produktion. Beheben Sie PHP2Shell jetzt mit 8.4 und behandeln Sie 8.6 als eigenes Projekt.

Zuletzt geprüft am 22. Oktober 2026.