Stand: 09.11.2026, PHP 8.6.0 RC5 released (05.11.2026) als letzter Release Candidate, GA am 19.11.2026 geplant
PHP 8.6.0 RC5 ist am 05.11.2026 als letzter Release Candidate erschienen. Wie schon RC4 vom 21.10.2026, der die Fixes für zwei kritische Sicherheitslücken brachte, enthält er seit dem Feature-Freeze nur noch Fehlerkorrekturen. Der Featureumfang steht fest: Partial Function Application, clamp(), Time\Duration, Io\Poll, readonly Properties mit Defaultwerten und sicherere Session-Defaults, True Async bleibt zurückgezogen. Das GA-Release ist für den 19.11.2026 angekündigt.
Release-Zeitplan PHP 8.6
Termin | Meilenstein | Status |
|---|---|---|
22.07.2026 | True Async RFC | withdrawn |
10.08.2026 | Abstimmung Deprecations for PHP 8.6 (31 von 35 angenommen) | confirmed |
25.08.2026 | Beta 2 | released |
24.09.2026 | RC2, Feature-Freeze (ein RC1 wurde nicht veröffentlicht) | released |
08.10.2026 | RC3 | released |
21.10.2026 | RC4 | released |
05.11.2026 | RC5 (letzter Release Candidate) | released |
19.11.2026 | PHP 8.6.0 GA | geplant |
31.12.2028 | Ende Active Support | geplant |
31.12.2030 | End of Life, Ende der Security-Fixes | geplant |
Quellen für die Termine sind die Release-Ankündigungen auf php.net, die Release-Übersicht auf php.watch und der offizielle Release-Zeitplan im PHP-Wiki. Der Zeitplan im Wiki ist ausdrücklich vorläufig: Einzelne Releases können je nach Entwicklungsstand hinzukommen oder entfallen. Ein Termin gilt erst mit der Ankündigung auf php.net als bestätigt.
Ein Hinweis zur Zählung: php.net nennt RC5 „the fourth release candidate“. Das liegt daran, dass RC1 wegen eines Packaging-Fehlers nie erschienen ist. Die Reihe begann deshalb mit RC2. In der RC5-Ankündigung der Release-Manager heißt es zum GA-Termin:
„8.6.0 should be expected in ~2 weeks, i.e. on 19 Nov 2026.“
RC4 schließt zwei kritische Sicherheitslücken
RC4 enthält laut php.net die Fixes für zwei kritische Schwachstellen, die eine Remote Code Execution ohne Anmeldung ermöglichen können (CVE-2026-109618 und CVE-2026-109619, in Sicherheitskreisen „PHP2Shell“ genannt). php.net empfiehlt allen, die frühere Builds von PHP 8.6.0 einsetzen, sofort zu aktualisieren. Das betrifft vor allem CI-Runner und Staging-Server, auf denen noch RC2 oder RC3 läuft. Laut linuxcompatible.org kamen seit RC3 außerdem rund 50 Fehlerkorrekturen hinzu.
True Async: zurückgezogen (withdrawn)
Der Unterschied zwischen „Declined“ und „Withdrawn“ ist mehr als Semantik. Eine abgelehnte RFC heißt, dass die Community dagegen gestimmt hat. Der Status „Withdrawn“ heißt, dass die Autoren den Vorschlag selbst zurückgezogen haben, bevor es zur finalen Abstimmung kam.
Bei True Async ist genau das passiert. Die RFC wurde am 25.12.2025 erstellt und am 22.07.2026 zuletzt aktualisiert, mit dem Status Withdrawn. Die beiden Companion-RFCs, die Engine-API und das Scope-Konzept für strukturierte Nebenläufigkeit, stehen weiter unter „Under discussion“. Ein Voting-Termin ist nicht absehbar. Ein Landing in einer späteren PHP-Version bleibt möglich, ist aber aktuell Spekulation.
Wer produktiv mit Async-PHP arbeitet, plant für 8.6 weiterhin mit ReactPHP, AMPHP oder Swoole. Thematisch ergänzend dazu sind die Background-Worker in FrankenPHP.
Partial Function Application v2 (confirmed, in RC4 enthalten)
PFA v2 ist angenommen und vollständig implementiert. Die Syntax nutzt ? für genau ein Argument und ... für eine variadische Anzahl:
// Platzhalter ? steht für genau ein Argument
$makeSlug = str_replace(' ', '-', ?);
echo $makeSlug('Hello World'); // Hello-World
// Zusammen mit dem Pipe-Operator aus PHP 8.5
$slug = ' Hello World '
|> trim(...)
|> str_replace(' ', '-', ?)
|> strtolower(...);Das passt zum Pipe-Operator aus PHP 8.5, der eine Callable mit genau einem Parameter verlangt. PFA liefert diese Callable, ohne dass Sie eine eigene Closure schreiben müssen.
Zwischen Alpha und Beta kam eine Nachschärfung dazu. Die Folge-RFC „Partial Function Application: Handling of Optional Parameters“ von Tim Düsterhus, Arnaud Le Blanc und Larry Garfield wurde am 20.04.2026 angenommen. Sie macht alle Platzhalter-Parameter zu Pflicht-Parametern, statt die Optionalität des Ziel-Parameters zu übernehmen. Der Grund ist Konsistenz: Eine Signatur, die für statische Analyse lesbar bleibt, wiegt schwerer als eine automatisch vererbte Optionalität.
Einschränkungen bleiben bestehen. Konstruktoren lassen sich nicht partiell anwenden. Für Referenzen gelten Sonderregeln. Benannte Platzhalter funktionieren nur unter Bedingungen und func_get_args() verhält sich anders als bei einem direkten Aufruf.
Io\Poll: Unterbau für I/O-Multiplexing (confirmed, in RC4 enthalten)
Die Polling-API im Namespace Io\Poll bringt mit Context, Event und StreamPollHandle ein schmales Set an Klassen für effizientes I/O-Multiplexing. Verfügbar sind epoll unter Linux und WSAPoll unter Windows, als Ersatz für stream_select() ab einer gewissen Skalierung.
// Stream auf Lesbarkeit überwachen, maximal fünf Sekunden warten
$context = new Io\Poll\Context();
$handle = $context->register($stream, Io\Poll\Event::Readable);
$context->wait(Time\Duration::fromSeconds(5));Diese API bringt keine neuen Async-Features und keinen Event-Loop. Sie ist Unterbau, gedacht für interne Entwicklung wie PHP-FPM und Signal-Handling in ZTS. Low-Level-Bibliotheken wie ReactPHP oder Amp können darauf eigene Backends aufbauen. Im Anwendungscode werden Sie Io\Poll selten direkt einsetzen.
clamp(), Time\Duration und weitere Ergänzungen (confirmed, in RC4 enthalten)
clamp() ist eine globale Funktion, die einen Wert auf einen Bereich begrenzt. Sie wirft einen ValueError, wenn $min größer als $max ist oder einer der beiden Werte NAN ist. Geprüft wird zuerst gegen das Maximum, dann gegen das Minimum. Die Funktion arbeitet mit Zahlen, mit nicht-numerischen Strings im lexikografischen Vergleich und mit vergleichbaren Objekten wie DateTimeImmutable.
// Seitengröße aus einem Query-Parameter absichern
$limit = clamp((int) $request->query->get('limit', 20), 1, 100);
// Funktioniert auch mit vergleichbaren Objekten
$deliveryDate = clamp(
$requestedDate,
new DateTimeImmutable('tomorrow'),
new DateTimeImmutable('+30 days'),
);Time\Duration ist eine readonly-Klasse mit Nanosekunden-Präzision für Zeitspannen. Sie bringt Methoden wie fromSeconds(), fromMilliseconds(), add() und multiplyBy() mit und lässt sich direkt über die Standard-Operatoren vergleichen.
Readonly Properties dürfen jetzt Defaultwerte tragen. Das ist seit den Property Hooks auf Interfaces in PHP 8.4 sinnvoll geworden. Das enum SortDirection { case Ascending; case Descending; } ersetzt die Integer-Konstanten SORT_ASC und SORT_DESC typsicher. Built-ins wie array_multisort() unterstützen das Enum allerdings noch nicht direkt.
Im Alltag nützlich sind drei kleinere Punkte. grapheme_strrev() kehrt Strings auf Ebene der Grapheme-Cluster um, was bei Emoji und kombinierten Zeichen anders arbeitet als das byte-basierte strrev(). Fehler bei json_decode() zeigen jetzt die Position im Payload an. Das Attribut #[Override] greift jetzt auch für Klassenkonstanten.
Mit Beta 2 sind außerdem drei Features durch die Soft-Freeze-Lücke gerutscht, weil Release-Manager Matteo Beccati zwei Tage vor dem Plan getaggt hat: eine SNMP-Überarbeitung mit AES-192 und AES-256, Endianness-Modifier für pack() und unpack() über < und > sowie die Möglichkeit, in Klassenkonstanten gespeicherte Objekte direkt zu mutieren.
Der Featureumfang von PHP 8.6 ist mit dem Feature-Freeze beim ersten Release Candidate abgeschlossen. PFA v2, Io\Poll, clamp(), Time\Duration, readonly Properties mit Defaultwerten und die sicheren Session-Defaults sind enthalten. True Async ist zurückgezogen.
::
Session-Defaults: das wichtigste Thema für Bestandsprojekte (confirmed, in RC4 enthalten)
Die Ini-Werte session.use_strict_mode, session.cookie_httponly und session.cookie_samesite stehen jetzt standardmäßig auf 1, 1 und Lax. Bisher waren sie aus oder ungesetzt. Passend dazu ist SessionHandler::validateId() jetzt tatsächlich implementiert, wodurch der Strict Mode überhaupt erst greift.
Das kann bestehendes Verhalten ändern. Extern gelieferte oder geteilte Session-IDs werden abgewiesen. JavaScript-Zugriff über document.cookie auf den Session-Cookie ist blockiert. Cross-Site-POST-Flows wie SP-initiiertes SAML-SSO oder ältere Cross-Origin-Formulare brauchen jetzt explizit SameSite=None; Secure.
In Symfony setzen Sie das nicht per ini_set(), sondern in der Framework-Konfiguration:
# config/packages/framework.yaml
# Nur nötig, wenn Ihr Setup auf Cross-Site-POST angewiesen ist
framework:
session:
cookie_samesite: none
cookie_secure: truePrüfen Sie vorher, ob das für die gesamte Anwendung gelten muss. Oft betrifft der Cross-Site-Flow nur einen einzelnen Login-Endpunkt. Wie sich die Symfony-Versionen zu PHP 8.6 verhalten, steht im Artikel zum aktuellen Stand der Symfony-8.x-Reihe.
Der Deprecation-Sweep: 31 von 35 angenommen (confirmed)
Die Sammel-RFC „Deprecations for PHP 8.6“, koordiniert von Gina P. Banyard, bündelte 35 Einzelabstimmungen. Das Voting schloss am 10.08.2026 um 13:00 UTC. Angenommen wurden 31 Vorschläge, 4 wurden abgelehnt. Deprecations bedeuten in 8.6 zunächst E_DEPRECATED-Hinweise. Eine Entfernung ist frühestens für PHP 9.0 zu erwarten.
Unter den angenommenen Deprecations sind Rückgabewerte aus __construct() und __destruct(), mysqli_get_charset() mit 100 Prozent Zustimmung und der Funktionsname readonly mit 97,5 Prozent. Letzteres macht einen bekannten Lexer-Workaround in WordPress überflüssig. Ebenfalls deprecated sind is_double(), is_integer(), is_long(), doubleval(), spl_object_hash() zugunsten von spl_object_id() sowie die CSV-Methoden von SplFileObject.
Vier Vorschläge scheiterten. Am knappsten war list() mit 23 zu 23 Stimmen bei einer Enthaltung, was die nötige Zweidrittelmehrheit klar verfehlte. Dieser Kandidat hatte mit 12.275 Vorkommen in 5.545 Dateien auch den höchsten gemessenen Impact. Abgelehnt wurden außerdem in, out und inout als reservierte Identifier, der dechunk-Stream-Filter sowie der _()-Alias für gettext.
Die abgelehnte dechunk-Deprecation hilft Symfony-Projekten. Der Filter wird intern vom HTTP-fopen-Wrapper genutzt und in userland von symfony/http-client sowie php-http/message referenziert. Symfony-Projekte werfen deshalb in 8.6 keine dechunk-Deprecation.
Deprecated-Nutzung im eigenen Code finden Sie am schnellsten mit PHPStan:
# Erweiterung installieren
composer require --dev phpstan/phpstan-deprecation-rules
# Analyse mit PHP 8.6 als Zielversion
vendor/bin/phpstan analyse --configuration=phpstan.neon
# phpstan.neon
includes:
- vendor/phpstan/phpstan-deprecation-rules/rules.neon
parameters:
phpVersion: 80600
level: 6
paths:
- srcAm 19.11. erscheinen auch 8.5.13 und 8.4.28
Seit dem 05.11.2026 stehen auch PHP 8.5.13 und PHP 8.4.28 als RC1 zum Testen bereit. Laut den Ankündigungen auf der internals-Liste sind beide finalen Versionen für den 19.11.2026 geplant (8.5.13RC1, 8.4.28RC1). Welche Sicherheitslücken offen sind und welche Builds gepatcht sind, pflegen wir in der Übersicht zum aktuellen PHP-Patchstand, dort auch den Stand zu CVE-2026-115560.
Parallele Releases: PHP 8.5.12 und 8.4.27 (final, 21.10.2026)
Parallel zu RC4 erschienen am 21.10.2026 die finalen Versionen PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 als Sicherheitsreleases. Sie schließen dieselben beiden Lücken. Welche Builds je Paketquelle bereits gepatcht sind, fasst die Übersicht aktueller PHP-Patchstand zusammen. Wer auf Shared- oder Managed-Hosting läuft, sollte außerdem prüfen, was Ihr Hoster bei PHP-Sicherheitslücken übernimmt. Welche Server zuerst dran sind und was hilft, wenn Sie nicht sofort aktualisieren können, steht im Artikel PHP-Sicherheitsupdate vom 21. Oktober 2026. Was 8.5 im Produktivbetrieb leistet, steht im Artikel PHP 8.5 in Produktion.
Was sich seit dem letzten Update geändert hat
- Update 09.11.2026: RC5 ist am 05.11.2026 als letzter Release Candidate erschienen. php.net zählt ihn als vierten Release Candidate, weil RC1 nie veröffentlicht wurde.
- Neu unter der Zeitplan-Tabelle: das Zitat der Release-Manager zum GA-Termin am 19.11.2026.
- Neuer Abschnitt zu PHP 8.5.13 und 8.4.28, die seit dem 05.11. als RC1 vorliegen und ebenfalls am 19.11. erscheinen sollen.
- Unverändert gilt: RC4 vom 21.10.2026 enthält die Fixes für zwei kritische RCE-Lücken, einen RC1 hat es nie gegeben.
Einordnung für bestehende Projekte
Mit dem Feature-Freeze ändert sich die Frage. Es geht nicht mehr darum, was in 8.6 landet, sondern wann Ihr Projekt umsteigt. Für produktive Systeme bleibt der Zeitpunkt vor dem 19.11.2026 eine Testphase. Bugs, die Sie jetzt gegen RC5 melden, können noch in die finale Version einfließen. Nach dem GA landen sie erst in einem Patch-Release.
Der pragmatische erste Schritt ist ein CI-Job gegen das Docker-Image php:8.6-rc-cli. Läuft die Testsuite grün, folgt der PHPStan-Lauf mit den Deprecation-Regeln. Den größten direkten Handlungsbedarf erzeugen die Session-Defaults, alles andere sind Hinweise ohne Laufzeitwirkung.
Symfony 7.4 LTS verlangt mindestens PHP 8.2 und läuft damit technisch auch auf 8.6. Die formale Freigabe neuer PHP-Minors durch Frameworks und Bibliotheken folgt erfahrungsgemäß mit einigen Wochen Abstand zum GA. Wer zwischen LTS und aktueller Version entscheidet, findet die Kriterien im Artikel Symfony LTS oder aktuelle Version. Wer ältere Codebasen erst auf einen upgradefähigen Stand bringen muss, sollte vorher klären, ob sich Legacy-PHP schrittweise modernisieren lässt.
Ich aktualisiere diesen Artikel zum GA-Release am 19.11.2026.
::cta-follow::