En resumen: Para PHP 8.1 y anteriores, el proyecto PHP ya no ofrece actualizaciones oficiales. El soporte a largo plazo, también llamado soporte extendido, procede de distribuciones Linux, repositorios de terceros o servicios comerciales como TuxCare ELS o Zend/HeroDevs. Puede cubrir el tiempo hasta la actualización si el proveedor confirma por escrito la cobertura para su versión. Pero no sustituye ni la actualización ni el mantenimiento del CMS y del código propio.
Por qué la pregunta se plantea precisamente ahora
El 21 de octubre de 2026 aparecieron las correcciones de PHP2Shell solo para las ramas compatibles 8.5, 8.4, 8.3 y 8.2. Para 7.4, 8.0 y 8.1, el proyecto PHP ha facilitado únicamente backports mínimos del código fuente, es decir, correcciones en el código sin versión lista. Según la prensa especializada, están afectadas casi todas las versiones hasta PHP 5.4.
El tamaño del parque lo muestra un análisis de CybelAngel: unos 2,24 millones de hosts PHP accesibles desde Internet, de los cuales, según CybelAngel, el 59 % funciona con versiones sin una corrección oficial próxima. Para muchas empresas, la cuestión del soporte a largo plazo deja así de ser teórica. Y va a crecer: PHP 8.2 llega al fin del soporte el 31 de diciembre de 2026.
Lo que un sistema heredado necesita ahora mismo lo describe PHP 8.1 y anteriores: qué rige ahora. Este artículo ayuda con la pregunta a medio plazo: ¿qué camino sostiene hasta la actualización y qué debe ofrecer?
Soporte extendido de PHP: los caminos de un vistazo
| Camino | Qué ofrece | Límites |
|---|---|---|
| Mantenimiento a largo plazo de la distribución | Backports en los paquetes mientras la versión de la distribución tenga soporte | solo para la versión de PHP que trae esa distribución |
| Repositorio de terceros | p. ej. sury.org, según informes con builds de 5.6 a 8.5 | no es el archivo de seguridad de la distribución, cuestión de confianza |
| Soporte comercial a largo plazo | paquetes parcheados para versiones fuera de soporte, p. ej. TuxCare ELS, Zend/HeroDevs | hacer confirmar la cobertura por versión y CVE, costes continuos |
| Construcción propia a partir de backports del código fuente | builds propios a partir de las correcciones del proyecto PHP | laborioso, necesario de nuevo con cada vulnerabilidad |
Sobre las ofertas comerciales: TuxCare describe en su sitio web correcciones de CVE para versiones fuera de soporte de PHP 5.2 a 8.x, entregadas mediante la gestión de paquetes existente, para Windows y las distribuciones Linux habituales. Una nota en la misma página informa de correcciones de PHP2Shell para versiones de PHP fuera de soporte. Según la documentación de cPanel, TuxCare promete para vulnerabilidades desde CVSS 7 correcciones en un plazo de 14 días tras su publicación; en servidores cPanel, para ello los dominios se pasan de ea-php a alt-php. Sobre Zend/HeroDevs no disponíamos de ninguna declaración acerca de la cobertura de PHP2Shell.
Indicaciones sobre el camino de terceros las ofrece el artículo El repositorio sury.org.
Qué necesita por escrito del proveedor
El soporte a largo plazo es un servicio de confianza. Usted compra la promesa de que se cerrarán las vulnerabilidades futuras. Por eso, antes de decidir, pida respuesta por escrito a lo siguiente:
- ¿Qué versiones de PHP, sistemas operativos y nombres de paquete están cubiertos exactamente?
- ¿Están cerradas CVE-2026-109618 y CVE-2026-109619 para su versión, con qué nivel de paquete y desde cuándo?
- ¿Cómo se tratará CVE-2026-115560 y los avisos posteriores?
- ¿Están incluidas las extensiones que usa o solo el núcleo de PHP?
- ¿Cómo comprueba usted mismo que un parche está aplicado, por ejemplo mediante el registro de cambios del paquete?
- ¿Cuánto dura la cobertura para su versión y cómo se anuncia un final?
- ¿Qué ocurre con los paquetes instalados cuando termina el contrato?
No bastan respuestas que remitan solo en general a «todas las vulnerabilidades de seguridad». Para auditores, aseguradoras y su propia documentación cuenta la asignación concreta de versión, paquete y CVE.
Los límites: lo que el soporte a largo plazo no resuelve
El soporte a largo plazo mantiene al día el entorno de ejecución de PHP. Todo lo que hay por encima sigue siendo tarea suya. Y precisamente ahí suele estar el mayor problema en los sistemas heredados.
- La aplicación sigue envejeciendo: un CMS o una tienda que necesita PHP 8.1 a menudo ya no se usa en su versión actual.
- Bibliotecas y extensiones: los paquetes de Composer y los plugins con frecuencia ya no reciben actualizaciones para versiones antiguas de PHP.
- No sustituye al reinicio ni a la revisión: también los paquetes parcheados solo actúan tras reiniciar todos los procesos de PHP, y no eliminan el software malicioso que se haya inyectado antes.
- La deuda técnica crece: cuanto más largo el puente, mayor el salto en la migración posterior.
- Los justificantes se vuelven más laboriosos: auditores, clientes y aseguradoras preguntan cada vez más por el nivel de parcheo. Una versión de PHP fuera de soporte con parches de terceros se puede acreditar, pero exige más explicación que una versión compatible.
¿Cuándo es el soporte a largo plazo, a pesar de todo, la elección correcta? Son típicas tres situaciones: una aplicación especializada cuyo fabricante aún no autoriza versiones más recientes de PHP; un sistema heredado cuya sustitución ya está decidida y que solo debe seguir funcionando unos pocos meses; o una gran base de código cuyo cambio hay que planificar con cuidado. En los tres casos, el soporte a largo plazo compra tiempo para una solución ordenada. No es una solución para sistemas de los que ya nadie quiere ocuparse.
Si un sistema heredado funcionó desprotegido en Internet entre el 17 y el 21 de octubre, aclare primero si está comprometido. El soporte a largo plazo para un sistema ya infectado no protege nada.
Un plan de salida forma parte de ello
El soporte a largo plazo es una buena decisión cuando termina en una fecha. Fije hasta cuándo debe funcionar la aplicación en una versión compatible, quién es responsable de la migración y qué hitos intermedios rigen. Cuánto tiempo se mantienen oficialmente las ramas de PHP lo explica El ciclo de lanzamiento de PHP.
Si para su sistema compensa más una actualización o un backport lo pondera el artículo ¿Actualización de PHP o backport?.
¿Cómo ayuda PHP SOS en concreto?
- Valorar la situación: revisamos versión, origen de los paquetes y nivel de parcheo de sus sistemas heredados, y si muestran huellas de un ataque.
- Revisar las ofertas: contrastamos los compromisos por escrito de un proveedor de soporte a largo plazo con su parque real.
- Asegurar el puente: hasta la actualización aplicamos las medidas provisionales de php.net y restringimos la accesibilidad.
- Ejecutar la salida: con la migración de PHP 8.1 y anteriores planificamos y probamos el cambio a una versión compatible.
Preguntas frecuentes
¿Qué es el soporte extendido de PHP?
Se refiere a ofertas que siguen suministrando correcciones de seguridad a versiones de PHP tras el fin oficial del soporte. Pueden ser distribuciones Linux, repositorios de terceros o servicios comerciales como TuxCare ELS o Zend/HeroDevs.
¿Cubre PHP2Shell el soporte comercial a largo plazo?
TuxCare indica en su sitio web haber suministrado correcciones de PHP2Shell para versiones de PHP fuera de soporte. Para su versión, su paquete y su sistema operativo concretos, debería hacérselo confirmar igualmente por escrito y verificarlo en el registro de cambios.
¿Es el soporte a largo plazo una alternativa a la actualización?
Solo de forma temporal. Mantiene parcheado el entorno de ejecución de PHP, pero no el CMS, las extensiones ni el código propio, que a menudo también están obsoletos. Por eso, una fecha de salida forma parte de toda decisión a favor del soporte a largo plazo.
¿Qué ocurre si termina el contrato de soporte a largo plazo?
Según la documentación de cPanel sobre TuxCare, los paquetes instalados siguen funcionando, pero ya no reciben nuevas actualizaciones de seguridad. El sistema queda entonces en la misma situación que antes, solo que más tarde.
¿Vale el tema también para PHP 8.2?
Sí, pronto. PHP 8.2 recibe todavía con la 8.2.35 la corrección de PHP2Shell, pero el 31 de diciembre de 2026 llega al fin del soporte. Quien opere la 8.2 debería planificar el cambio ahora.