PHP 8.2 recibe correcciones de seguridad del proyecto PHP hasta el 31 de diciembre de 2026. A partir de esa fecha, la versión llega al final de su ciclo de vida: no habrá más actualizaciones, ni siquiera para vulnerabilidades críticas. En este artículo se explica qué significa para una aplicación en producción y cómo planificar la actualización a una versión con soporte.
Qué significa el fin del soporte
Cada rama de PHP tiene dos años de soporte activo y, después, otros dos años en los que solo se corrigen problemas de seguridad críticos. Tras esos cuatro años, llega al final de su ciclo de vida y deja de tener soporte (php.net: versiones con soporte, en inglés). Para una versión en esa situación, php.net recomienda actualizar cuanto antes, ya que puede quedar expuesta a vulnerabilidades sin corregir.
Nada deja de funcionar el 1 de enero de 2027. La aplicación sigue en marcha; lo que termina son las correcciones. Una vulnerabilidad descubierta después de esa fecha no se corregirá en ninguna versión oficial de PHP 8.2.
Versiones con soporte después del 31 de diciembre de 2026
| Versión | Correcciones de seguridad hasta |
|---|---|
| PHP 8.3 | 31 de diciembre de 2027 |
| PHP 8.4 | 31 de diciembre de 2028 |
| PHP 8.5 | 31 de diciembre de 2029 |
Fuente: php.net: versiones con soporte (en inglés). PHP 8.4 u 8.5 dejan más margen hasta la siguiente actualización; 8.3 es un paso menor, pero deja de tener soporte un año después.
Paso 1: compruebe qué versión utiliza realmente
La versión que importa es la que sirve la aplicación, que no siempre coincide con la de los ordenadores de los desarrolladores. Revise todos los entornos: producción, preproducción, micrositios antiguos y herramientas internas.
- En un hosting compartido, la versión suele aparecer en el panel de control del hosting, y a menudo se puede cambiar allí.
- En un servidor,
php -vmuestra la versión de la línea de comandos; el servidor web puede utilizar otra a través de PHP-FPM. Los paquetes instalados en el servidor indican cuál utiliza el sitio. - En un contenedor, la etiqueta de la imagen base, por ejemplo
php:8.2-fpm, indica la versión.
Paso 2: compruebe su distribución de Linux
Si PHP se instala desde los paquetes de la distribución, cuenta también el soporte de seguridad de la distribución, no solo las fechas del proyecto PHP. Debian 12 (bookworm) incluye PHP 8.2; el equipo de soporte a largo plazo (LTS) de Debian cubre bookworm hasta el 30 de junio de 2028, salvo algunos paquetes, que se pueden consultar con el paquete debian-security-support (anuncio de Debian, en inglés). Debian 13 (trixie) incluye PHP 8.4 (packages.debian.org). Ubuntu 24.04 LTS incluye PHP 8.3, y Ubuntu 26.04 LTS, PHP 8.5 (packages.ubuntu.com).
El soporte de la distribución da margen, pero no cambia las versiones de PHP que admite su framework o su CMS.
Paso 3: compruebe qué admite su framework o CMS
- WordPress recomienda PHP 8.3 o superior (requisitos de WordPress, en inglés). Los plugins y temas deben revisarse uno a uno.
- Laravel 12 admite de PHP 8.2 a 8.5 y recibe correcciones de seguridad hasta el 24 de febrero de 2027; Laravel 13 requiere PHP 8.3 o superior (notas de versión de Laravel, en inglés).
- Symfony 8 requiere PHP 8.4 o superior (Symfony 8.0, en inglés).
- Drupal 11 requiere PHP 8.3 o superior, así que no funciona con 8.2 (requisitos de PHP de Drupal, en inglés).
En un proyecto con Composer, composer why-not php 8.4 muestra los paquetes que impiden pasar a la nueva versión.
Paso 4: pruebe la nueva versión antes de cambiar
La forma más segura de probar una nueva versión de PHP es un entorno aparte y reproducible que replique producción: las mismas extensiones y la misma configuración, cambiando solo la versión de PHP. Una imagen de contenedor permite repetirlo en todo el equipo y, después, en producción. Para cada versión, PHP publica una guía de migración con los cambios incompatibles: PHP 8.3, PHP 8.4, PHP 8.5.
Ejecute las pruebas automatizadas, si las hay, y recorra los procesos principales de la aplicación. Los avisos de funciones obsoletas en los registros indican qué puede fallar en una versión posterior.
Si la actualización no puede terminarse a tiempo
Mantenga PHP 8.2 en su última versión hasta finales de diciembre y reduzca lo que queda expuesto: áreas de administración sin uso, rutas antiguas, instalaciones de prueba olvidadas. Una regla de cortafuegos puede filtrar algunos ataques, pero no corrige una vulnerabilidad del propio PHP, así que conviene que el plan de actualización siga avanzando.
Cómo puedo ayudarle
Ayudo a pequeñas y medianas empresas a llevar sus aplicaciones PHP a una versión con soporte sin reescribirlas: una evaluación de qué se ejecuta y dónde, un entorno reproducible en contenedores para la actualización y, opcionalmente, el alojamiento y la gestión. Los cambios en el código de la aplicación siguen en manos de su equipo de desarrollo o de su agencia.