En resumen: Tras PHP2Shell son probables más avisos sobre PHP, porque ya dos días después del parche llegó un tercer aviso, aún falta un aviso de seguridad completo y las distribuciones entregan sus paquetes de forma escalonada. Quien establezca ahora un procedimiento fijo de seguimiento, valoración, actualización y reinicio reaccionará ante la próxima vulnerabilidad nueva de PHP en horas en lugar de en días.
El parche no fue el final de la historia
El 21 de octubre de 2026 el proyecto PHP cerró las dos vulnerabilidades críticas CVE-2026-109618 y CVE-2026-109619 con las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Muchos responsables marcaron entonces el asunto como hecho. Dos días después, el 23 de octubre, llegó sin embargo otro aviso de php.net sobre CVE-2026-115560.
Este tercer aviso afecta solo a una configuración de sesión inusual. Pero muestra un patrón conocido en los grandes casos de seguridad: cuando un componente se pone de pronto en el foco, muchos especialistas miran a la vez con más atención. Si de ahí surgirán más vulnerabilidades, hoy no lo sabe nadie. Pero es probable que el flujo de noticias no se corte.
Para usted como administrador significa: cuente con avisos posteriores en lugar de sorprenderse con cada uno. La secuencia de los acontecimientos hasta ahora la resume nuestra cronología de PHP2Shell.
Por qué son probables más avisos
La siguiente valoración se basa en hechos conocidos públicamente. No es una predicción de vulnerabilidades concretas.
- Falta aún un aviso de seguridad. php.net trata CVE-2026-115560 dentro del ciclo de versiones regular y ha anunciado que publicará el aviso completo con la próxima versión. Hasta entonces,
session.upload_progress.enabled=0se considera la medida paliativa. - Los detalles fueron públicos pronto. Según varios informes, se conocieron detalles antes de que terminara el embargo. Según los informes, watchTowr reprodujo CVE-2026-109618, según sus propias indicaciones. Trabajos así suelen llevar a nuevas preguntas sobre partes de código vecinas.
- Las distribuciones entregan de forma escalonada. Ubuntu atendió el 21 de octubre las versiones actuales con USN-8948-1 y entregó después, con USN-8948-2, correcciones para 14.04 a 20.04 mediante Ubuntu Pro. Red Hat escribió en su boletín que algunas actualizaciones estaban disponibles y otras en preparación.
- La versión de desarrollo está afectada. Según php.net, también PHP 8.6.0 RC4 contiene las correcciones. Quien prueba versiones previas debe actualizar también esos entornos.
- Las versiones antiguas siguen abiertas. Para PHP 8.1 y anterior solo hay backports mínimos del código fuente. Cada proveedor que entrega esas versiones comunica su estado por su cuenta y en sus propios plazos.
Cómo le llega una nueva vulnerabilidad de PHP
Los avisos llegan por distintas vías y con distinta fiabilidad. El orden es casi siempre el mismo: primero el proyecto PHP, luego las distribuciones y los proveedores de alojamiento, después las autoridades y los medios.
| Fuente | Qué averigua allí | Qué fiabilidad tiene |
|---|---|---|
| php.net | Ramas afectadas, versiones corregidas, medidas provisionales | Fuente primaria |
| Ubuntu, Debian, Red Hat | Niveles de paquetes por versión, momento de entrega | Fuente primaria para su sistema |
| Proveedores de alojamiento y de paneles | Estado de sus propias compilaciones de PHP | Solo vinculante si es por escrito |
| BSI, CERT-Bund (el CERT del Gobierno alemán) | Valoración de la situación, nivel de alerta, recomendaciones | Valoración de las autoridades |
| Prensa especializada y empresas de seguridad | Observaciones de ataques, cifras, antecedentes | Útil, tratar como informe |
Es importante la diferencia entre «hay un parche» y «mi sistema tiene el parche». La primera afirmación está en php.net. La segunda debe acreditarla usted para cada servidor.
Suscríbase a los avisos de php.net y de su distribución por RSS o lista de correo y reenvíelos a un buzón común o a un canal que lea más de una persona. Las vacaciones y las bajas por enfermedad son los motivos más frecuentes de actualizaciones tardías.
Qué debería preparar antes del próximo aviso
La experiencia de PHP2Shell muestra dónde se pierde tiempo: al buscar servidores, al aclarar responsabilidades y en el reinicio olvidado. Todo eso puede resolverse de antemano.
- Inventario: una lista de todos los servidores y sitios web con rama de PHP, modo de ejecución (PHP-FPM, mod_php, LiteSpeed) y origen de los paquetes. Sin esa lista, cada aviso empieza buscando. Cómo conseguirlo lo describe el artículo Inventario de todos los sitios web y servidores.
- Responsabilidad: para cada sistema está fijado quién parchea, quién reinicia y quién da el visto bueno. Con proveedores de alojamiento y agencias, eso debe constar en el contrato.
- Esquema de valoración: bastan tres preguntas para la primera clasificación. ¿Está afectada nuestra rama? ¿Usamos la función o el modo de ejecución afectado? ¿Hay un parche o solo medidas provisionales?
- Vía de pruebas: un entorno de staging en el que una actualización de PHP pueda comprobarse en poco tiempo.
- Justificante: un formato fijo en el que se anoten el nivel de paquetes, la coincidencia en el registro de cambios y la hora del reinicio.
Cómo funciona un procedimiento así como rutina en lugar de como intervención de bomberos figura en La gestión de parches como proceso. Los antecedentes sobre cómo trata el proyecto PHP las vulnerabilidades los ofrece la página Cómo trata el proyecto PHP las vulnerabilidades de seguridad.
La propia configuración como sistema de alerta temprana
Una parte de los avisos posteriores afecta solo a determinados ajustes. CVE-2026-115560 es un ejemplo: php.net indica como condición que una aplicación cambie en tiempo de ejecución el serializador de sesión mientras el seguimiento de subida está activo. Las aplicaciones que nunca hacen eso no están afectadas, según php.net.
Quien conoce su configuración efectiva puede clasificar esos avisos más rápido. Por eso anote para cada rama qué valores están fijados en el servidor y qué aplicaciones pueden sobrescribirlos. Ya ayuda una simple comparación de los ajustes activos:
# Valores efectivos de la línea de comandos (la configuración web puede diferir)
php -i | grep -E "session.upload_progress.enabled|session.serialize_handler|memory_limit|post_max_size"
# Valores fijados en los pools de FPM (la ruta varía según la distribución)
grep -RhE "php_(admin_)?value" /etc/php/*/fpm/pool.d/ 2>/dev/null
La línea de comandos no muestra necesariamente lo que rige en el contexto web. Dan claridad la configuración del pool o del VirtualHost y, de forma breve y protegida, una página phpinfo.
Otra ventaja: quien sabe qué valores provisionales siguen fijados desde la semana de PHP2Shell puede revisarlos de forma consciente tras la próxima versión regular. Algunos ajustes, como el seguimiento de subida desactivado, pueden seguir siendo razonables de forma permanente. Otros, como límites de subida muy ajustados, conviene adaptarlos de nuevo a la necesidad real tras consultar con los departamentos especializados.
¿Cómo ayuda PHP SOS en concreto?
- Seguimos los avisos de php.net, de las distribuciones y del BSI y valoramos los nuevos avisos para sus sistemas concretos.
- Elaboramos con usted el inventario de todas las instalaciones de PHP y fijamos las responsabilidades de cada servidor.
- En el marco de un contrato de mantenimiento de seguridad aplicamos actualizaciones, reiniciamos todos los procesos y documentamos el estado.
- En los avisos sin parche aplicamos medidas provisionales no sobrescribibles y las comprobamos después.
Preguntas frecuentes
¿Hay ya una nueva vulnerabilidad de PHP tras PHP2Shell?
El 23 de octubre de 2026 php.net publicó un aviso sobre CVE-2026-115560. Según este, la ejecución de código solo es posible con una configuración de sesión inusual. Un aviso de seguridad completo debe seguir con la próxima versión regular.
¿Debo actuar de inmediato ante cada aviso nuevo?
No todos los avisos exigen la misma urgencia. Lo decisivo son la gravedad, si su configuración está afectada y si hay un parche disponible. Un procedimiento establecido ayuda a valorarlo en minutos en lugar de en días.
¿Dónde me entero primero de nuevas vulnerabilidades de PHP?
Las fuentes primarias son los avisos de php.net y las notas de seguridad de su distribución, por ejemplo los Ubuntu Security Notices, el Debian Security Tracker o Red Hat. El BSI (Oficina Federal alemana para la Seguridad de la Información) informa mediante sus alertas. Los informes de los medios ayudan, pero suelen llegar más tarde y ser menos precisos.
¿Por qué las distribuciones a veces avisan días después que php.net?
Las distribuciones tienen que incorporar la corrección a sus propios paquetes, compilarla y probarla. Para versiones más antiguas puede tardar más o solo ofrecerse mediante ofertas adicionales. Por eso merece la pena seguir ambas fuentes por separado.