En resumen: la cronología de PHP2Shell recoge hasta ahora cuatro fechas documentadas: un primer intento de ataque observado el 17/10, el preaviso de php.net el 20/10, los parches el 21/10 a las 16:00 hora alemana y un nuevo aviso sobre CVE-2026-115560 el 23/10/2026. Para los administradores, esto significa: aplicar el parche, reiniciar todos los procesos de PHP y guardar los registros, como muy tarde, desde el 20/10.
Por qué una cronología de PHP2Shell importa a los administradores
Con una vulnerabilidad de esta gravedad no basta con saber si su servidor está parcheado hoy. También es decisivo cuánto tiempo fue vulnerable antes. Esa ventana de tiempo determina qué registros debe guardar, qué archivos debe revisar y si puede descartar con fundamento una intrusión.
PHP2Shell afecta a PHP en sí, no a un CMS concreto. Dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, permiten ejecutar código malicioso de forma remota y sin autenticación. Ambas están valoradas con CVSS v4.0 9.2. Encontrará una introducción comprensible en ¿Qué es PHP2Shell?.
La cronología siguiente contiene solo datos documentados a fecha de 25/10/2026. Cuando un dato se basa en informes de los medios, así se indica.
| Fecha | Suceso | Fuente |
|---|---|---|
| 17/10/2026 | Primer intento de ataque observado (Amazon) | Informes de los medios |
| 20/10/2026 | Preaviso de php.net | php.net |
| 21/10/2026, 14:00 UTC | Publicación de los parches (16:00 hora alemana) | php.net |
| 23/10/2026 | Aviso sobre CVE-2026-115560 | php.net |
| 25/10/2026 | Fecha de esta recopilación | – |
17 de octubre: el primer intento de ataque observado
Según informes de los medios, el 17/10/2026 se observó un primer intento de ataque, comunicado por Amazon. Fue cuatro días antes de los parches. Hubo, por tanto, un periodo en el que ya se intentaban ataques pero todavía no existía ninguna actualización.
No está documentado si ni cuántos ataques tuvieron éxito en esa fase. Lo importante es la consecuencia para su propia revisión: un servidor que hoy está parcheado puede haber sido comprometido antes. Un parche no elimina el software malicioso que ya se haya introducido ni demuestra que antes no ocurriera nada.
20 y 21 de octubre: preaviso y parches
El 20/10/2026 el proyecto PHP anunció en php.net las actualizaciones de seguridad. El 21/10/2026 a las 14:00 UTC, es decir, a las 16:00 hora alemana, llegaron las versiones corregidas.
| Rama | Última versión vulnerable | Corregida en |
|---|---|---|
| PHP 8.5 | 8.5.11 | 8.5.12 |
| PHP 8.4 | 8.4.26 | 8.4.27 |
| PHP 8.3 | 8.3.35 | 8.3.36 |
| PHP 8.2 | 8.2.34 | 8.2.35 |
Para PHP 8.1 y anteriores ya no hay actualizaciones oficiales, solo backports mínimos del 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. Los modos de ejecución afectados son PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El equipo de PHP ve el mayor riesgo en mod_php, donde se demostró un exploit antes de que se ejecute siquiera el código de la aplicación.
Las distribuciones y los proveedores de hosting aplican en parte backports. En ese caso, Plesk, por ejemplo, sigue mostrando 8.2.34 aunque el servidor esté parcheado. Lo que cuenta es el estado de los paquetes y la confirmación del proveedor, no el número de versión que se muestra. Cómo comprobarlo correctamente se explica en Cómo comprobar bien la versión de PHP y el estado del parche.
23 de octubre: aviso sobre CVE-2026-115560
El 23/10/2026 el proyecto PHP publicó otro aviso, esta vez sobre CVE-2026-115560. Según este, solo se puede explotar con una configuración poco habitual: en la configuración figura el serialize_handler php_binary o php_serialize, la aplicación lo cambia a php mediante ini_set() antes de session_start() y el seguimiento de progreso de subida de sesión está activo.
La mitigación es sencilla y conviene aplicarla con independencia de que conozca o no esa combinación en su entorno:
; en php.ini, en el pool de FPM o en la configuración del servidor
; no mediante ini_set() ni .user.ini
session.upload_progress.enabled = 0
Después, reinicie todos los workers de PHP. El aviso completo debe publicarse con la próxima versión regular de corrección de errores. Hasta entonces, este ajuste sigue siendo la solución transitoria recomendada.
Situación a 25 de octubre: panorama y preguntas abiertas
El BSI (Oficina Federal alemana para la Seguridad de la Información) ha declarado el nivel de alerta 3 / naranja. Recomienda la actualización inmediata y, si no es posible hacerla enseguida, desconectar temporalmente los servidores web de la red. El BSI contaba con una explotación masiva y rápida; según el BSI, al principio no se conocían ataques exitosos confirmados a gran escala. La valoración del BSI se resume en la página Qué recomienda el BSI sobre PHP2Shell.
Cloudflare comunicó intentos de ataque observados y ha desplegado reglas de protección, pero advierte de que las reglas basadas únicamente en los datos de la petición no bastan. Palo Alto Networks (Unit 42) contabilizó más de 22,6 millones de instancias expuestas y potencialmente vulnerables. No se han publicado Indicators of Compromise confirmados; la detección se basa en el análisis de comportamiento.
Algunos proveedores desconectaron sus sitios web como medida preventiva. Eso no significa automáticamente que esos sitios hayan sido hackeados. Lo que sigue abierto, a fecha de esta recopilación, es sobre todo cuántos servidores fueron realmente comprometidos antes del parche.
Qué significa la cronología para sus registros y revisiones
De los datos se desprenden tres periodos: antes del 17/10, entre el 17/10 y el momento de su propio parche y reinicio, y después. El periodo intermedio es el crítico. Cuanto más duró en su caso, más exhaustiva debería ser la revisión.
La prensa especializada recomienda conservar los registros del servidor desde el 20/10/2026. Guarde también los registros anteriores que existan antes de que la rotación automática los elimine.
Una forma sencilla de guardar los registros sin modificarlos y dejar constancia de su estado:
# Guardar los registros en conjunto (adapte las rutas a su sistema)
sudo tar czf /root/logs-sicherung-$(date +%F).tar.gz /var/log/apache2 /var/log/nginx /var/log/php*
# Suma de comprobación como prueba posterior
sha256sum /root/logs-sicherung-*.tar.gz
# ¿Cuánto tiempo conserva el sistema los registros?
grep -R "rotate" /etc/logrotate.d/
Anote además cuándo exactamente se instaló la actualización y cuándo se reiniciaron los procesos de PHP. Los archivos nuevos por sí solos no protegen mientras sigan ejecutándose procesos antiguos en memoria. Cómo analizar los registros guardados se describe en la guía Analizar los registros del servidor web tras un ataque.
¿Cómo ayuda PHP SOS en concreto?
- Determinamos con usted la ventana de vulnerabilidad real de su servidor: estado de los paquetes, momento del parche y reinicio de todos los workers.
- Guardamos los registros y el estado del sistema de forma trazable antes de modificar nada.
- Buscamos comportamientos anómalos, como archivos PHP nuevos, procesos ajenos y conexiones salientes inusuales.
- Documentamos el resultado de modo que la dirección, los delegados de protección de datos y las aseguradoras puedan trabajar con él.
El procedimiento en detalle se describe en nuestra ayuda inmediata PHP2Shell.
Preguntas frecuentes
¿Cuándo se publicaron los parches de PHP2Shell?
El proyecto PHP publicó las versiones corregidas el 21/10/2026 a las 14:00 UTC, es decir, a las 16:00 hora alemana. Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
¿Desde qué fecha debería conservar los registros del servidor?
La prensa especializada recomienda conservar los registros desde el 20/10/2026. Como, según informes de los medios, ya el 17/10 se observó un primer intento de ataque, conviene guardar también los registros anteriores que existan antes de que la rotación los elimine.
¿Es CVE-2026-115560 tan peligrosa como las dos primeras vulnerabilidades?
Según el aviso del 23/10/2026, solo se puede explotar con una configuración de sesiones poco habitual. Como medida de mitigación se indica session.upload_progress.enabled=0 hasta que salga la próxima versión regular de corrección de errores.
¿Hay Indicators of Compromise confirmados sobre PHP2Shell?
No, a fecha de 25/10/2026 no se ha publicado ningún Indicator of Compromise confirmado. La detección se basa en el análisis de comportamiento, por ejemplo procesos inusuales, archivos nuevos y conexiones llamativas.