On November 5, 2026, the PHP project released PHP 8.6.0 RC5 and said the next release will be the first stable one, PHP 8.6.0, planned for November 19. Among the backward incompatible changes listed in the UPGRADING file, the one most likely to change a production application without a single new line of code is in sessions: three settings now ship with stricter values.
What changes in PHP 8.6 sessions
The change comes from the "Secure Session Configuration Defaults" RFC, accepted with a separate vote for each setting. The new values apply both as PHP's built-in defaults and in the php.ini-production file that ships with 8.6.
Setting | Up to PHP 8.5 | In PHP 8.6 | Effect |
|---|---|---|---|
session.use_strict_mode | 0 | 1 | rejects session IDs that do not exist in storage |
session.cookie_httponly | 0 | 1 | page JavaScript can no longer read the session cookie |
session.cookie_samesite | empty | Lax | the cookie is not sent on POST requests coming from another site |
All three guard against known problems: session fixation (someone plants an ID and waits for the victim to log in with it), cookie theft by injected script, and requests forged from another site. The RFC itself shows that Laravel, Symfony and Django already use HttpOnly and Lax in their session settings.
The release also brings a long list of deprecations, such as return inside finally and the mbregex extension, deprecated because the Oniguruma library is no longer maintained. Those deprecations produce warnings; the session change alters how the application behaves.
Which applications may break
The biggest risk is in flows that need the session cookie on a POST that started on another domain. The RFC mentions SP-initiated SAML login and legacy forms submitted across origins. By the same Lax rule, any return that arrives by POST from an external system and relies on the user's session belongs on the test list.
Chrome, Firefox and Edge already treat cookies without the attribute as Lax; Safari does not, according to the RFC's table. In practice, a flow that currently only works in Safari is likely to be the first to fail.
Also worth checking:
- front-end code that reads the session cookie through
document.cookie, for example to pass the ID in a header; - custom session handlers that accept IDs from outside, such as handing a session over between subdomains. The default Redis and Memcached handlers are not affected, according to the RFC;
- classes implementing
SessionHandlerInterfacewithoutcreate_sid()andvalidateId(), which now emit a deprecation notice.
The change applies to the default value. A server that keeps its old php.ini, with session.use_strict_mode = 0 written explicitly, keeps the previous behavior after the upgrade. Whoever runs the server needs to know which file is in effect, because the outcome can go either way: the protection may never arrive, or a flow may break without anyone touching the configuration.
What to do before and after November 19
There is no reason to put 8.6.0 in production on release day. The RC5 announcement itself asks that it not be used in production. What makes sense now is testing in staging or CI:
- record today's session values in production (
php -i | grep sessionorini_get()) to compare later; - run single sign-on, payment and any integration that sends the user back by POST against RC5;
- search for JavaScript that reads the session cookie;
- review custom session handlers.
For anyone choosing a version, the nearest date is a different one. According to the supported versions page, PHP 8.2 gets its last security fix by December 31, 2026, and PHP 8.4 leaves active support on the same day, keeping security fixes only until the end of 2028. Teams still on 8.2 have a little over seven weeks to move, and the choice now includes the target: 8.5, already stable, or 8.6 with the session change. I wrote about why a supported version still calls for a migration decision; for anyone on 8.2, that decision now has a date.
What is still unknown
The November 19 date is "planned", in the announcement's words, and can move if RC5 turns up a problem. The sources consulted also do not say when Linux distributions, Docker images and managed hosts will offer 8.6, or whether they will keep customers' old php.ini during the upgrade. Framework and plugin compatibility with 8.6 depends on each project and does not appear in these sources yet.
If your company is weighing something similar, reach me on LinkedIn or WhatsApp.
