En resumen: si la opción correcta es actualizar PHP o aplicar un backport depende de cuánto tiempo deba seguir funcionando su sistema y de lo bien acreditado que esté el backport. Un backport de la propia distribución en un sistema operativo compatible es un camino de pleno valor. Los backports de código fuente, las fuentes de terceros y el soporte comercial a largo plazo para PHP 8.1 y anteriores son puentes con fecha de caducidad. A largo plazo solo ayuda pasar a una versión de PHP que el proyecto PHP siga soportando oficialmente.
Por qué la pregunta apremia tras PHP2Shell
El 21 de octubre de 2026, el proyecto PHP corrigió PHP2Shell en las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Para PHP 8.1 y anteriores ya no hay lanzamientos oficiales, solo backports mínimos de código fuente para 7.4, 8.0 y 8.1. Según la prensa especializada, están afectadas casi todas las versiones hasta PHP 5.4.
Así, muchos operadores de sistemas antiguos se enfrentan a la misma pregunta: ¿basta con parchear la vulnerabilidad de alguna manera, o hay que hacer ya la actualización que se lleva años aplazando? Lo que significa en la práctica una actualización lo describe nuestra oferta de migración desde PHP 8.1 y anteriores. Lo que vale sin actualización oficial figura en PHP 8.1 y anteriores: qué se aplica ahora. Este artículo ayuda a ponderar entre ambas.
Qué tipos de backport existen
«Backport» es un término genérico. Siempre significa que una corrección de una versión más nueva se traslada a una más antigua. Pero quién lo hace y lo bien revisado que esté difiere mucho.
- Backport de la distribución: Debian, Ubuntu, Red Hat y otras incorporan correcciones de seguridad a los paquetes de PHP de sus versiones soportadas. El número de versión suele seguir igual; según los informes, por ejemplo Ubuntu 24.04 sigue mostrando 8.3.6 tras la actualización. La corrección se acredita mediante el registro de cambios del paquete y los avisos de seguridad de la distribución.
- Fuente de terceros: el repositorio sury.org de Ondřej Surý ha puesto a disposición, según los informes, compilaciones para todas las ramas de la 5.6 a la 8.5. No es el archivo de seguridad de Debian. Los detalles figuran en El repositorio sury.org.
- Backport de código fuente del proyecto PHP: para 7.4, 8.0 y 8.1 hay parches mínimos en el código fuente, pero no lanzamientos terminados. Quien los usa debe compilar PHP por sí mismo, probarlo y mantenerlo en el futuro.
- Soporte comercial a largo plazo: proveedores como TuxCare ELS o Zend/HeroDevs ofrecen mantenimiento para versiones antiguas. Si cubren PHP2Shell y desde cuándo debe confirmarse por escrito; en las fuentes conocidas no estaba acreditado. Más información en Soporte a largo plazo para versiones antiguas de PHP.
Actualizar PHP o backport: la comparación
| Criterio | Actualización a una versión compatible | Backport (según el tipo) |
|---|---|---|
| Protección frente a PHP2Shell | Sí, con 8.2.35, 8.3.36, 8.4.27 u 8.5.12 | Sí, si es completo y está acreditado |
| Futuras actualizaciones de seguridad | Oficiales hasta el fin del soporte de la versión | Solo mientras el proveedor correspondiente lo mantenga |
| Prueba documental | Número de versión más reinicio | Registro de cambios del paquete con números CVE, confirmación del proveedor |
| Esfuerzo ahora | Medio a alto, hacen falta pruebas de compatibilidad | Bajo con la distribución, alto con compilación propia |
| Esfuerzo después | Bajo hasta el siguiente salto de versión | Crece con cada nueva vulnerabilidad |
| Riesgo para la aplicación | Incompatibilidades con código y extensiones antiguos | Bajo, el comportamiento sigue siendo en gran medida el mismo |
| Idoneidad como solución permanente | Sí | Solo el backport de la distribución en un sistema operativo compatible |
La fila «Esfuerzo después» es la más importante. PHP2Shell no habrá sido la última vulnerabilidad. Cada mes en una versión sin soporte oficial significa que el próximo aviso planteará de nuevo la misma pregunta.
¿Qué versión de destino para la actualización?
Según php.net, para cada rama de PHP rige: dos años de soporte activo, después dos años solo de correcciones de seguridad. De ahí resultan estas fechas de fin del soporte de seguridad:
| Versión | Soporte de seguridad hasta |
|---|---|
| PHP 8.2 | 31 de diciembre de 2026 |
| PHP 8.3 | 31 de diciembre de 2027 |
| PHP 8.4 | 31 de diciembre de 2028 |
| PHP 8.5 | 31 de diciembre de 2029 |
Una actualización a 8.2 es por ello solo una breve estación intermedia. Quien de todos modos migra debería apuntar a una versión con un horizonte más largo, siempre que el CMS, la tienda y las extensiones la soporten. Eso se comprueba en los requisitos del sistema del fabricante, no de memoria. Cómo funciona el ciclo de lanzamientos lo explica Versiones de PHP y ciclo de lanzamientos.
Sea cual sea el camino: tras la instalación hay que reiniciar todos los procesos de PHP. Un backport que solo está en el disco no protege mientras sigan en memoria los workers antiguos.
Un orden pragmático para sistemas antiguos
- De inmediato: aplicar las medidas transitorias según php.net o sacar temporalmente el sistema de la red si no hay una corrección acreditada disponible.
- En los próximos días: instalar un backport acreditado, a ser posible de la propia distribución o con confirmación escrita del proveedor.
- En paralelo: comprobar la compatibilidad de la aplicación con una versión compatible y fijar un calendario.
- En los próximos meses: actualización a la versión de destino, preparada en una copia de prueba, con plan de retorno.
Ver el backport como puente, no como meta, es la idea decisiva.
Cuándo no necesita para ello un proveedor de servicios
Si su servidor funciona con un Debian, Ubuntu o RHEL compatible y la distribución ofrece el backport, basta una actualización regular con reinicio y una mirada al registro de cambios. Un administrador con experiencia lo logra por sí solo. La ayuda compensa en compilaciones propias, fuentes de terceros, versiones muy antiguas o una aplicación cuya compatibilidad ya nadie domina.
¿Cómo ayuda PHP SOS en concreto?
- Comprobamos qué versiones de PHP y fuentes de paquetes funcionan en sus servidores y si hay una corrección acreditada.
- Instalamos backports, reiniciamos y documentamos la prueba mediante el registro de cambios.
- Probamos su aplicación en una copia contra la versión de destino y señalamos las incompatibilidades.
- Planificamos y acompañamos la actualización en el marco de la migración desde PHP 8.1 y anteriores.
Conclusión
El backport de la distribución es un camino de pleno valor; todos los demás backports son puentes. Quien se haya quedado en PHP 8.1 o anterior debería usar el backport para ganar tiempo para la actualización, no para seguir aplazándola.
Preguntas frecuentes
¿Es un backport igual de seguro que una actualización?
Para la vulnerabilidad concreta corregida, un backport puede ser equivalente si es completo y está acreditado. Pero solo corrige lo que se ha retroportado. Una actualización a una versión compatible aporta además todas las futuras actualizaciones de seguridad oficiales.
¿Cómo reconozco que mi backport cubre PHP2Shell?
En el registro de cambios del paquete: allí deberían figurar los números CVE-2026-109618 y CVE-2026-109619. En Debian y Ubuntu lo muestra apt-get changelog; en la familia RHEL, rpm -q --changelog. El número de versión por sí solo no es una prueba.
¿Hasta cuándo recibe PHP 8.2 actualizaciones de seguridad?
Según php.net, el soporte de seguridad de PHP 8.2 termina el 31 de diciembre de 2026. Quien actualice hoy a 8.2 debería planificar también el siguiente paso desde ya.
¿Compensa el soporte comercial a largo plazo para versiones antiguas de PHP?
Puede ser un puente si una actualización es imposible a corto plazo. Pida que le confirmen por escrito si PHP2Shell está cubierto y desde cuándo. En las fuentes conocidas hasta ahora no estaba acreditado.