En resumen: La ventana de tiempo entre parche y ataque fue negativa en PHP2Shell: según los medios hubo un primer intento de ataque ya el 17 de octubre de 2026, cuatro días antes de las actualizaciones. Para los administradores, por eso, la pregunta no es «¿cuánto tiempo queda?», sino «¿cuánto tiempo está abierto mi servidor?». Esa ventana personal solo termina cuando la actualización está instalada y todos los procesos de PHP se han reiniciado.
El punto de partida: ataques antes del parche
Durante mucho tiempo se dio por válida una suposición cómoda: entre la actualización de seguridad y los primeros ataques pasan algunos días, tiempo suficiente para la siguiente ventana de mantenimiento. PHP2Shell ha refutado esa suposición. Según los medios, que citan a Amazon, se observó un primer intento de ataque ya el 17 de octubre. Cloudflare informó igualmente de ataques tempranos. Los parches llegaron el 21 de octubre a las 14:00 UTC.
Este artículo explica cómo surgen estas ventanas de tiempo y cómo acortar la suya. La secuencia exacta de fechas la encuentra en la cronología de PHP2Shell.
La ventana de tiempo entre parche y ataque, por fases
En torno a una vulnerabilidad de seguridad pueden distinguirse varias fases. En PHP2Shell fueron así:
| Fase | En general | En PHP2Shell |
|---|---|---|
| Antes de hacerse pública | la vulnerabilidad solo la conocen quienes la descubrieron y el fabricante | desarrollo de la corrección bajo embargo |
| Primeros ataques sin parche | los atacantes aprovechan la vulnerabilidad antes de que exista una actualización | según los medios, primer intento el 17 de octubre |
| Preaviso | el fabricante anuncia la actualización | 20 de octubre, php.net anuncia la versión |
| Parche disponible | aparecen la actualización y el aviso de seguridad | 21 de octubre, 14:00 UTC |
| Análisis del parche | investigadores y atacantes analizan los cambios | watchTowr reprodujo CVE-2026-109618, según sus propias indicaciones |
| Explotación generalizada | campañas automatizadas contra servidores sin parchear | prevista por el BSI; ataques exitosos confirmados de forma generalizada inicialmente no conocidos |
| Su parche | actualización y reinicio en sus servidores | individual |
La última fila es la única sobre la que usted puede influir. Todo lo anterior lo determinan otros.
Por qué el propio parche aumenta la presión
Una actualización de seguridad cierra la vulnerabilidad, pero a la vez la hace visible. Los cambios en el código fuente de proyectos de código abierto como PHP son públicos. Quien compara las diferencias entre la versión antigua y la nueva averigua en qué punto estaba el fallo. Eso no es un reproche al proyecto PHP, sino lo normal en el software abierto y la base para que las distribuciones puedan crear backports.
Para los administradores se deduce: con cada día tras el parche crece el número de quienes saben cómo funciona la vulnerabilidad. Al mismo tiempo disminuye el número de servidores sin parchear. Los que quedan se convierten así en los objetivos más evidentes. Cómo entrega PHP las actualizaciones de seguridad en el marco de su mantenimiento de versiones lo explica el artículo sobre el ciclo de publicación de PHP.
Si su servidor fue accesible entre el 17 de octubre y su parche, hay que hacer una búsqueda de indicios. Conserve los registros desde el 20 de octubre antes de que se pierdan por la rotación.
Medir su propia ventana de tiempo
Su ventana de tiempo personal empieza, como muy tarde, con la publicación de los parches y termina con el reinicio del último proceso de PHP. Anote para cada servidor:
- Conocimiento: ¿cuándo se enteró alguien de la empresa de la vulnerabilidad?
- Disponibilidad: ¿cuándo estuvo listo el paquete de su distribución o de su proveedor de alojamiento?
- Instalación: ¿cuándo se aplicó?
- Reinicio: ¿cuándo dejó de haber procesos antiguos de PHP en ejecución?
Justo el reinicio se olvida a menudo. Una actualización instalada solo surte efecto cuando los procesos antiguos han terminado. Cómo comprobarlo lo describe Reiniciar PHP-FPM y todos los procesos de PHP. Si aún hay procesos anteriores a la actualización en ejecución, lo muestra un vistazo a las horas de inicio:
# Mostrar la hora de inicio de todos los procesos de PHP
ps -eo pid,lstart,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep
Si la hora de inicio es anterior a la instalación de la actualización, la ventana sigue abierta.
Por qué su ventana depende de la vía de obtención
La rapidez con que puede parchear no depende solo de usted, sino también de dónde procede su PHP. Las distribuciones entregaron backports, según los informes, en parte ya el 21 de octubre. Quien obtiene PHP de un repositorio de terceros depende del ritmo de este. Quien usa contenedores debe reconstruir y desplegar imágenes; una simple actualización dentro del contenedor en funcionamiento no basta. Y en el alojamiento compartido es el proveedor quien decide el momento.
Si conoce la vía de obtención de cada servidor, sabrá también en qué punto su ventana permanece abierta más tiempo. Justo ahí es donde más compensa la preparación, por ejemplo con un acuerdo con el proveedor de alojamiento o un procedimiento probado para nuevas imágenes de contenedor.
Cómo acortar la ventana de tiempo la próxima vez
- Suscribirse a los avisos: recibir directamente los avisos de seguridad de php.net y de su distribución, no solo a través de la prensa.
- Fijar la responsabilidad: para cada servidor, una persona responsable con suplente.
- Usar la automatización donde encaje: las actualizaciones de seguridad de la distribución pueden aplicarse automáticamente. Qué lo favorece y qué lo desaconseja lo describe Actualizaciones de seguridad automáticas.
- Planificar el reinicio: el reinicio de los servicios de PHP forma parte fija del procedimiento, no de la posproducción.
- Preparar la vía de emergencia: página de emergencia y decisión sobre una desconexión temporal por si una actualización no es posible de inmediato.
- Llevar un justificante: documentar las horas de instalación y reinicio para poder acreditar después su ventana.
Un proceso permanente que reúne estos puntos se describe en el artículo sobre el proceso de gestión de parches.
¿Cómo ayuda PHP SOS en concreto?
- Parche y reinicio: aplicamos la actualización y nos aseguramos de que no queden procesos antiguos de PHP en ejecución.
- Acreditar la ventana de tiempo: documentamos la instalación y el reinicio de cada servidor con su hora.
- Revisión de indicios: para el periodo en que su servidor estuvo abierto, conservamos los registros y buscamos anomalías.
- Proceso para el futuro: definimos con usted las vías de aviso, las responsabilidades y los procedimientos de actualización.
Más información en el servicio de parcheo de PHP.
Conclusión
En PHP2Shell no hubo periodo de gracia. La ventana de tiempo entre parche y ataque en vulnerabilidades críticas hoy suele ser cero o incluso negativa. Lo que usted puede controlar es su propia ventana: termina con el reinicio y, con preparación, puede acortarse de días a horas.
Preguntas frecuentes
¿Cuánto tiempo queda tras una actualización de seguridad hasta que llegan los ataques?
No hay un plazo fijo. En PHP2Shell, según los medios, se observó un primer intento de ataque ya el 17 de octubre, es decir, cuatro días antes de los parches. En vulnerabilidades críticas de software extendido, debe partir de la base de que prácticamente no hay periodo de gracia.
¿Qué es un zero-day?
Una vulnerabilidad que se ataca antes de que haya una actualización disponible. El fabricante tuvo, por así decirlo, cero días para corregirla. Después se habla a menudo de una vulnerabilidad conocida o N-day, para la que ya existe un parche.
¿Por qué los ataques suelen aumentar tras un parche?
Con el parche se hace público en qué punto estaba el fallo. Los investigadores de seguridad y los atacantes pueden analizar los cambios. Al mismo tiempo, muchos servidores siguen sin parchear durante días o semanas y por tanto siguen siendo objetivos rentables.
¿Cuándo está mi servidor realmente protegido?
Cuando la actualización está instalada y todos los procesos de PHP se han reiniciado. Los archivos nuevos por sí solos no surten efecto mientras haya procesos antiguos en la memoria. El final de su ventana de tiempo personal es, por tanto, el reinicio, no la descarga.