PHP 8.6 session defaults are now locked. Beta 3 shipped on September 10, 2026, past the point where the three ini flips in the secure session configuration defaults RFC could still be pulled. They change how every PHP process on a server handles session cookies, not just the one running your storefront. For Magento and Hyva stores the storefront is largely covered already. Everything else on the box is not, and that is where this lands.
What changed on September 10, 2026
PHP 8.6 beta 3 carries three session ini defaults that flip from permissive to secure. session.use_strict_mode goes from 0 to 1, session.cookie_httponly goes from 0 to 1, and session.cookie_samesite goes from unset to Lax. The RFC passed with no votes against on any of the three proposals, at 27 to 0, 26 to 0 with one abstention, and 26 to 0, with voting closing in May 2026. You can read the full rationale and vote breakdown in the secure session configuration defaults RFC.
The schedule after beta 3 is short. Hard feature freeze is September 22, RC 1 lands September 24, and 8.6.0 goes GA on November 19, 2026. Beta 3 is the last beta. The PHP release announcements carry the dated entries. Nothing about these defaults is going to change between now and November.
PHP 8.6 session defaults vs Magento's own cookie config
Magento already sets SameSite to Lax on its session cookie, so the storefront sees almost no change. Magento configures session cookie parameters explicitly in application code rather than inheriting them from php.ini, which means the runtime default was never what governed PHPSESSID on a Magento request. The ecosystem has been living with Lax since 2.4.3 and has built the workarounds already: proxy forms that re-submit from the store's own origin, session checker plugins around the payment return, the whole pattern PayPal's integration uses.
What does inherit php.ini is everything that calls session_start() without going through Magento's session manager. Standalone scripts dropped into pub/. Webhook receivers that answer a gateway or an ERP and were written as one file because they only had to work once. Status dashboards. Vendor admin panels bolted next to the store. A BFF layer sitting in front of a headless storefront. None of those read Magento's config, and all of them are about to get strict mode, HttpOnly and Lax whether their authors planned for it or not.
The comparison matters because it tells you where to look. If your only PHP is Magento, this upgrade is close to a no-op. If your server also runs the four small PHP things that accumulated around the store over six years, that is your exposure.
use_strict_mode is the flip that changes behaviour
Strict mode rejects session IDs the server never issued, and that is the only one of the three that changes runtime behaviour rather than cookie attributes. HttpOnly and SameSite are instructions to the browser. Strict mode is a decision the PHP process makes about a value it receives: if the ID in the cookie does not correspond to a session PHP created, it discards it and starts fresh instead of adopting it. That closes session fixation, which is why it was proposed, and rejected, as far back as 2016 before passing unanimously this year.
It also breaks any integration that hands a session ID across a boundary and expects the other side to honour it. SSO handoffs that pass an ID in a query string. Load test scripts that seed a fixed session to skip login. Legacy connectors that mint an ID themselves. Those all worked because PHP would adopt an unknown ID on sight. From 8.6 they get a new empty session instead, and the failure reads as "user is randomly logged out" rather than as anything pointing at sessions.
No Magento line runs PHP 8.6 at GA, and that is the trap
Magento 2.4.9 runs on PHP 8.4 and 8.5, so no supported Magento line will be certified for PHP 8.6 on November 19. That sounds like permission to ignore this, and it is the opposite. It means the flip will not reach you through a Magento upgrade, where you would test it. It reaches you through infrastructure, where you will not.
The realistic path is ops bumping the base image for a side service, or a shared FPM pool picking up the new runtime, or a container spec that says the PHP major and minor loosely enough to drift. The storefront stays pinned and healthy. The webhook receiver on the same pool starts issuing Lax cookies and rejecting seeded session IDs, and the first symptom is a payment provider's callback silently losing state on a Tuesday. This is the same shape as every other runtime default change: the component you tested is fine, the component nobody owns is the one that moves.
What we would change this quarter
Stop relying on php.ini defaults entirely and set the three values explicitly, at the pool level, today. If your FPM pool config states session.use_strict_mode, session.cookie_httponly and session.cookie_samesite as literal values, the 8.6 upgrade cannot change them, and you have converted a silent behavioural change into a config decision you made on purpose. That is a fifteen minute job and it is the whole mitigation.
Then find the callers. Grep the full server tree, not just the Magento root, for session_start() and for direct writes to $_SESSION, and list every file that is not inside Magento's session manager. That list is your actual test plan. For anything in it that participates in a payment return, an SSO handoff or a cross origin POST, exercise it against Lax and strict mode now rather than after the runtime moves under it. The open Magento issue on external gateway POST redirects is a good read before you do, because it documents exactly how this failure presents and why SameSite None is the wrong fix.
The broader point is that this is a maintenance decision, not a feature decision. We treat runtime defaults the way we treat dependency pinning on Magento and Hyva builds: state the value, own the value, and never let an upgrade decide it for you. The same rule governs how we handle deployment and infrastructure work. Defaults that change under you are not a security improvement if you did not know they changed.