El 5 de noviembre de 2026, el proyecto PHP publicó PHP 8.6.0 RC5 e informó que la próxima versión será la primera estable, PHP 8.6.0, prevista para el 19 de noviembre. Entre los cambios incompatibles que enumera el archivo UPGRADING, el que más puede alterar una aplicación en producción sin una sola línea de código nueva está en la sesión: tres configuraciones pasan a venir con valores más restrictivos.
Qué cambia en la sesión de PHP 8.6
El cambio viene de la RFC "Secure Session Configuration Defaults", aceptada con una votación separada para cada configuración. Los nuevos valores rigen tanto como valor por defecto interno de PHP como en el php.ini-production que acompaña a la versión 8.6.
Configuración | Hasta PHP 8.5 | En PHP 8.6 | Efecto |
|---|---|---|---|
session.use_strict_mode | 0 | 1 | rechaza IDs de sesión que no existen en el almacenamiento |
session.cookie_httponly | 0 | 1 | el JavaScript de la página ya no puede leer la cookie de sesión |
session.cookie_samesite | vacío | Lax | la cookie no se envía en un POST que viene de otro sitio |
Las tres protegen contra problemas conocidos: fijación de sesión (alguien planta un ID y espera a que la víctima inicie sesión con él), robo de la cookie por un script inyectado y peticiones falsificadas desde otro sitio. La propia RFC muestra que Laravel, Symfony y Django ya usan HttpOnly y Lax en su configuración de sesión.
La versión también trae una lista larga de deprecaciones, como return dentro de finally y la extensión mbregex, marcada como obsoleta porque la biblioteca Oniguruma dejó de mantenerse. Esas deprecaciones generan avisos; el cambio en la sesión altera el comportamiento de la aplicación.
Qué aplicaciones pueden romperse
El riesgo mayor está en los flujos que dependen de que la cookie de sesión llegue en un POST que empezó en otro dominio. La RFC cita el inicio de sesión SAML iniciado por el proveedor de servicio y los formularios heredados enviados entre orígenes distintos. Por la misma regla de Lax, cualquier retorno que llegue por POST desde un sistema externo y cuente con la sesión del usuario entra en la lista de pruebas.
Chrome, Firefox y Edge ya tratan como Lax las cookies sin el atributo; Safari no, según la tabla de la RFC. En la práctica, un flujo que hoy solo funciona en Safari tiende a ser el primero en fallar.
También requieren atención:
- el código front-end que lee la cookie de sesión con
document.cookie, por ejemplo para pasar el ID en una cabecera; - los handlers de sesión propios que aceptan IDs llegados de fuera, como el traspaso de sesión entre subdominios. Los handlers por defecto de Redis y Memcached no se ven afectados, según la RFC;
- las clases que implementan
SessionHandlerInterfacesincreate_sid()nivalidateId(), que pasan a emitir un aviso de deprecación.
El cambio afecta al valor por defecto. Un servidor que conserva su php.ini antiguo, con session.use_strict_mode = 0 escrito de forma explícita, mantiene el comportamiento anterior después de actualizar. Quien administra el servidor necesita saber cuál de los dos archivos está en uso, porque el resultado puede ir en ambos sentidos: la protección puede no llegar, o un flujo puede romperse sin que nadie haya tocado la configuración.
Qué hacer antes y después del 19 de noviembre
No hay motivo para poner 8.6.0 en producción el día del lanzamiento. El propio anuncio del RC5 pide que no se use en producción. Lo que corresponde ahora es probar en preproducción o en el CI:
- registrar los valores de sesión actuales en producción (
php -i | grep sessionoini_get()) para comparar después; - ejecutar con el RC5 los flujos de inicio de sesión único, de pago y cualquier integración que devuelva al usuario por POST;
- buscar JavaScript que lea la cookie de sesión;
- revisar los handlers de sesión propios.
Para quien decide la versión, la fecha más cercana es otra. Según la página de versiones soportadas, PHP 8.2 recibe su última corrección de seguridad hasta el 31 de diciembre de 2026, y PHP 8.4 sale del soporte activo ese mismo día y queda solo con correcciones de seguridad hasta finales de 2028. Quien sigue en 8.2 tiene algo más de siete semanas para salir, y la elección ahora incluye la versión de destino: 8.5, ya estable, o 8.6 con el cambio de sesión. Escribí sobre por qué una versión con soporte también exige decidir cuándo migrar; para quien está en 8.2, esa decisión ya tiene fecha.
Lo que todavía no se sabe
La fecha del 19 de noviembre está "planificada", en palabras del anuncio, y puede cambiar si el RC5 revela algún problema. Las fuentes consultadas tampoco dicen cuándo las distribuciones Linux, las imágenes Docker y los hostings gestionados ofrecerán 8.6, ni si mantendrán el php.ini antiguo de los clientes al actualizar. La compatibilidad de frameworks y plugins con 8.6 depende de cada proyecto y todavía no aparece en estas fuentes.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
