En resumen: PHP End of Life significa que el proyecto PHP ya no ofrece actualizaciones de seguridad para esa rama. PHP2Shell muestra claramente las consecuencias: para PHP 8.1 y anteriores no hay corrección oficial, y PHP 8.2 termina el 31/12/2026. Quien hoy funciona con una rama antigua debería planificar el salto ahora, no en la próxima emergencia.
Qué significa PHP End of Life
El proyecto PHP mantiene cada rama, por ejemplo 8.2 u 8.3, solo durante un periodo limitado. Primero hay correcciones de errores y actualizaciones de seguridad y, más adelante, solo actualizaciones de seguridad. Después, el soporte termina por completo. php.net publica los periodos vigentes en su página de versiones con soporte.
Tras el fin del soporte, el software sigue funcionando. Pero si se conoce una vulnerabilidad nueva, el proyecto PHP ya no ofrece parche. El servidor sigue siendo vulnerable hasta que otra parte lo corrija o hasta que usted cambie a una rama con soporte.
Para la dirección y la jefatura de TI, es sobre todo una cuestión de planificación. Una migración se puede preparar con calma. Con prisa, tras un aviso crítico, resulta cara y arriesgada.
Qué muestra PHP2Shell sobre las versiones obsoletas
El 21/10/2026 el proyecto PHP publicó parches para dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619. Ambas permiten ejecutar código malicioso de forma remota y sin autenticación, y están valoradas con CVSS v4.0 9.2. Según la prensa especializada, están afectadas casi todas las versiones hasta PHP 5.4.
| Rama | Estado según el proyecto PHP | Corrección de PHP2Shell |
|---|---|---|
| PHP 8.5 | con soporte | 8.5.12 |
| PHP 8.4 | con soporte | 8.4.27 |
| PHP 8.3 | con soporte | 8.3.36 |
| PHP 8.2 | con soporte hasta el 31/12/2026 | 8.2.35 |
| PHP 8.1, 8.0, 7.4 | sin actualizaciones oficiales | solo backports mínimos del código fuente |
| PHP 7.3 y anteriores | sin actualizaciones oficiales | sin backport del proyecto PHP |
Para 8.1 y anteriores solo queda, por tanto, el camino de los backports de distribuciones o de proveedores de hosting. Estos suelen seguir mostrando el número de versión antiguo aunque estén parcheados. Solo el proveedor puede confirmar de forma vinculante si se ha incorporado un backport. Encontrará los detalles en la página PHP 8.1 y anteriores: qué rige ahora y la visión de conjunto completa en ¿Qué versiones de PHP están afectadas?.
PHP 8.2 aún ha recibido la corrección de PHP2Shell, pero llega al fin del soporte el 31/12/2026. Quien migre ahora desde 8.1 debería apuntar directamente a una rama más reciente.
Los riesgos de las versiones obsoletas de PHP, de un vistazo
El riesgo de seguridad es lo primero, pero no el único. Las versiones obsoletas de PHP arrastran otros problemas:
- Sin parches para vulnerabilidades nuevas: cualquier debilidad futura queda abierta o depende de backports de terceros.
- Bibliotecas obsoletas: los paquetes actuales exigen ramas más recientes de PHP. Entonces ya no se pueden instalar las correcciones de seguridad de las bibliotecas, como muestra la guía composer audit.
- Dependencia del proveedor: los proveedores de hosting a veces cobran recargos por versiones antiguas o dejan de ofrecerlas. El plazo lo marca entonces el proveedor, no usted.
- Problemas de acreditación: frente a aseguradoras, clientes o en auditorías, una versión sin soporte es difícil de justificar. Si de ello se derivan consecuencias contractuales o legales, acláralo con la aseguradora o con un abogado.
- Esfuerzo de migración creciente: cuanto mayor es la distancia con la versión actual, más código hay que adaptar.
Los más afectados con frecuencia son los sistemas de tienda antiguos y los desarrollos a medida que llevan mucho tiempo sin tocarse. Un ejemplo típico es Shopware 5, que a menudo sigue funcionando con ramas antiguas de PHP.
Inventario: ¿qué versiones de PHP se ejecutan en su entorno?
El primer paso es una imagen completa. En muchos servidores se ejecutan varias versiones de PHP en paralelo, por ejemplo para un sitio web antiguo que ya nadie tiene presente. Estos comandos solo leen:
# Versión de la línea de comandos
php -v
# Versiones instaladas en Debian/Ubuntu
ls /etc/php/
# Versiones instaladas en Plesk
ls /opt/plesk/php/ 2>/dev/null
# Procesos de PHP en ejecución con la versión en el nombre
ps -eo user,cmd | grep -E "[p]hp-fpm|[p]hp[0-9.]*-cgi|[l]sphp" | sort | uniq -c
Anote para cada sitio web: dominio, versión de PHP, modo de ejecución, CMS con su versión, persona responsable. Esa lista es también la base de su plan de emergencia. En el hosting compartido, las versiones suelen encontrarse en el menú de cliente del proveedor.
Planificar la migración: cómo proceder
Una migración a una rama con soporte sigue, por lo general, los mismos pasos, con independencia del sistema:
- Fijar el objetivo: elegir una rama que, según php.net, tenga soporte durante el mayor tiempo posible y que, según los requisitos del sistema del fabricante, encaje con su CMS.
- Comprobar la compatibilidad: CMS, extensiones, temas y código propio. Los datos figuran en la página oficial de cada fabricante.
- Montar un entorno de preproducción: una copia del sitio web con la nueva versión de PHP, incluida la base de datos.
- Probar: todos los procesos importantes, del formulario de contacto al proceso de pedido, y revisar en el registro de errores si hay advertencias.
- Cambiar y reiniciar: cambiar la versión, reiniciar todos los procesos de PHP, comprobar el funcionamiento y el registro de errores.
Sea realista en la planificación. Un sitio web pequeño con un CMS actual suele migrarse rápido. Una tienda crecida a lo largo de años, con muchas extensiones y código propio, en cambio, puede requerir adaptar código y extensiones, incluso pasar a una nueva versión principal del sistema de tienda. Aclare pronto quién decide internamente, de qué presupuesto se dispone y si hay que contar con desarrolladores externos.
Defina además cómo seguirá en el futuro los finales de soporte. Una fecha fija al año en la que contraste la lista de sus sitios web con los datos de php.net evita que el mismo cuello de botella vuelva a surgir dentro de dos años.
Hasta la migración, debería usar las medidas transitorias de php.net, por ejemplo session.upload_progress.enabled=0 en la configuración del servidor. No son una protección completa, pero reducen el riesgo.
¿Cómo ayuda PHP SOS en concreto?
- Registramos todas las versiones de PHP, modos de ejecución y aplicaciones de sus servidores.
- Valoramos el riesgo de cada sitio web y definimos con usted el orden y la versión de destino.
- Aplicamos medidas transitorias hasta la migración y recabamos del proveedor confirmaciones sobre los backports.
- Migramos a través de un entorno de preproducción y documentamos la prueba y el cambio.
El desarrollo lo describe el servicio PHP 8.1 y anteriores: migración a una versión con soporte.
Preguntas frecuentes
¿Cuándo termina el soporte de PHP 8.2?
PHP 8.2 llega al fin del soporte del proyecto PHP el 31/12/2026. La rama aún recibió la corrección de PHP2Shell con la versión 8.2.35; para vulnerabilidades posteriores, a partir de entonces ya no cabe esperar una actualización oficial.
¿Recibe PHP 8.1 un parche contra PHP2Shell?
El proyecto PHP ya no ofrece actualizaciones oficiales para 8.1 y anteriores. Solo existen backports mínimos del código fuente para 7.4, 8.0 y 8.1. Si su proveedor de hosting o su distribución los incorpora, y cómo, debe preguntárselo al proveedor.
¿Es segura una versión antigua de PHP con backports del hosting?
Los backports pueden cerrar vulnerabilidades concretas, pero no sustituyen a una rama con soporte. Dependen del proveedor, a menudo llegan más tarde y no cubren todas las vulnerabilidades. Por eso no sirven como solución a largo plazo.
¿Cómo sé si mi CMS funciona con una versión nueva de PHP?
Consulte los requisitos del sistema en la página oficial del fabricante y pruebe en un entorno de preproducción. Con las extensiones y los temas ocurre lo mismo, porque a menudo son el verdadero cuello de botella.