El futuro de PHP

En resumen: el futuro de PHP está fijado en lo esencial y se puede consultar públicamente. Cada versión recibe cuatro años de soporte, dos de ellos solo con correcciones de seguridad, siempre hasta el 31 de diciembre. PHP 8.6 está previsto, según la planificación, para el 19/11/2026 y trae, entre otras cosas, valores por defecto de sesión más seguros. Para PHP 9.0 hay propuestas de cambio aprobadas, pero ninguna fecha anunciada. Para las empresas significa: actualizaciones planificables en lugar de sorpresas, mientras usen versiones con soporte.

Cómo se decide el futuro de PHP

Las funciones y reglas nuevas surgen en PHP mediante RFC (Request for Comments). Una propuesta se publica en el wiki de PHP, se debate en la lista de correo y después se vota. Para los nuevos valores por defecto de sesión, por ejemplo, según el RFC hizo falta una mayoría de dos tercios. Solo un RFC aprobado y aplicado es una planificación documentada; las propuestas en debate son ideas, no compromisos.

Para quienes toman decisiones es una ventaja: quien quiere saber qué viene puede leer la lista del wiki en lugar de fiarse de rumores. En esta página, por eso, mencionamos solo RFC aprobados o aplicados y fechas oficiales.

Plazos de soporte fijos: cuatro años por versión

En 2024, el proyecto PHP adaptó el ciclo de versiones mediante un RFC. Desde entonces rige: dos años de soporte activo con correcciones de errores y de seguridad y, después, dos años solo para problemas de seguridad críticos. Los plazos terminan de forma uniforme el 31 de diciembre. Los release candidates ya no pueden contener funciones nuevas.

Los valores de 8.2 a 8.5 proceden de php.net; los de 8.6 los hemos deducido de la regla vigente y solo serán vinculantes cuando php.net los publique. Qué significa esto para las versiones antiguas lo describen Versiones de PHP y ciclo de versiones y PHP End of Life: riesgos de las versiones obsoletas.

PHP 8.6: lo que está decidido

Según el calendario del wiki de PHP, la publicación de PHP 8.6.0 está prevista para el 19/11/2026. El 21/10/2026 salió el cuarto release candidate, que según php.net ya contiene las correcciones de las dos vulnerabilidades de PHP2Shell; las versiones de prueba anteriores de 8.6 deben sustituirse. El siguiente release candidate está anunciado para el 05/11/2026. Las versiones de prueba no pertenecen a producción.

Una selección de los RFC que el wiki recoge como aplicados para PHP 8.6:

1. Valores por defecto de sesión seguros: session.use_strict_mode y session.cookie_httponly se activan por defecto, y session.cookie_samesite pasa a Lax.
2. Argumentos de funciones en los mensajes de error: datos adicionales que ayudan a depurar.
3. Limitación de las cadenas de filtros: un tope para el número de filtros encadenados.
4. Nuevos recursos del lenguaje: entre otros, clamp(), la aplicación parcial de funciones y valores por defecto para propiedades readonly.
5. Anuncio de obsolescencia: los valores devueltos por __construct() y __destruct() se marcan como obsoletos.

Lo que ya llegó con PHP 8.0 a 8.5 lo resume PHP 8.0 a 8.5: las novedades más importantes.

PHP 9.0: propuestas aprobadas, sin fecha

Varios RFC prevén expresamente cambios para PHP 9.0 y están aprobados, pero aún no aplicados. Entre ellos: error en lugar de advertencia con variables y propiedades no definidas, la eliminación de la notación ${} en cadenas de texto, la eliminación de los ID de sesión mediante GET y POST y el fin de los tipos de parámetro implícitamente anulables. En php.net no hay anunciada ninguna fecha de publicación para PHP 9.0.

Para la planificación significa: el código que hoy genera advertencias por funciones obsoletas debería depurarse ya. Así, el salto posterior no será un gran proyecto.

En el wiki hay además muchas propuestas en debate, como un binario común para la línea de comandos y FPM o la concurrencia en el motor. Si llegarán es algo abierto.

Quién sostiene PHP

PHP lo mantienen voluntarios y desarrolladores remunerados. Para cada versión hay un equipo de release managers; para PHP 8.6, el wiki menciona a Daniel Scherzer, Matteo Beccati y Joe Ferguson. La PHP Foundation describe como su misión asegurar la prosperidad a largo plazo del lenguaje y, según su propia descripción, financia a un equipo de desarrolladores a tiempo parcial y completo para el mantenimiento, la seguridad y las nuevas funciones.

También se moderniza la infraestructura: desde PHP 8.5, OPcache está integrado de forma permanente, y mediante un RFC se decidió recomendar PIE para las extensiones y marcar PECL como obsoleto.

Qué significa el futuro de PHP para su seguridad

PHP2Shell ha mostrado lo importantes que son los plazos de soporte. Para 8.2 a 8.5 llegaron correcciones oficiales el 21/10/2026; para 8.1 y anteriores solo hubo ya backports mínimos del código fuente. PHP 8.2 termina el 31/12/2026. Quien planifica hoy debería tener presentes tres cosas:

• Cada versión en uso necesita un fin de soporte conocido en el calendario.
• El cambio a la siguiente versión con soporte debe hacerse con tiempo antes de esa fecha.
• Los nuevos estándares, como los ajustes de sesión seguros de 8.6, son bienvenidos, pero no sustituyen una configuración deliberada.

¿Cómo ayuda PHP SOS en concreto?

En la migración a una versión de PHP con soporte procedemos así:

• Parque y plazos: registramos todas las versiones de PHP e incorporamos su fin de soporte a su plan.
• Comprobar la capacidad de actualización: mostramos qué aplicaciones y extensiones bloquean una versión nueva.
• Realizar el cambio: prueba, migración, reinicio y control, versión por versión.
• Mirar hacia delante: seguimos los RFC y las fechas de las versiones y avisamos cuando un cambio afecta a sus sistemas.

Preguntas frecuentes

Fuentes

• php.net: versiones con soporte
• PHP RFC: Release cycle update
• RFC de PHP (visión general)
• PHP RFC: Secure Session Configuration Defaults