En resumen: Una semana después del primer intento de ataque observado, PHP2Shell es hoy sobre todo una cuestión de aplicación: los parches para PHP 8.2 a 8.5 están disponibles desde el 21 de octubre, las grandes distribuciones han seguido, el BSI alerta con el nivel naranja. Se han observado intentos de ataque; el BSI inicialmente no comunicó ataques exitosos confirmados de forma generalizada. Siguen abiertas las versiones antiguas, los servidores no reiniciados y la pregunta de qué ocurrió antes del parche.
La situación en tres frases
PHP2Shell son dos vulnerabilidades críticas en el propio intérprete de PHP, CVE-2026-109618 y CVE-2026-109619, ambas puntuadas con CVSS v4.0 9,2. Permiten la ejecución de código a distancia sin autenticación, es decir, el caso que más temen los especialistas en seguridad. Están afectados PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed; el mayor riesgo lo ve el equipo de PHP en mod_php.
Este resumen ordena la situación a 25 de octubre de 2026 por actores. La secuencia día a día la encuentra en la cronología de PHP2Shell; aquí se trata del panorama de conjunto.
Qué está comprobado tras una semana
Son seguros los datos del proyecto PHP: las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 del 21 de octubre cierran ambas vulnerabilidades. Para PHP 7.4, 8.0 y 8.1 solo hay backports mínimos del código fuente, no versiones oficiales. php.net subraya que no existen medidas provisionales completas y que la actualización es la única vía segura.
El 23 de octubre se añadió un aviso sobre CVE-2026-115560. Afecta solo a una configuración de sesión inusual; como medida paliativa, php.net menciona session.upload_progress.enabled=0 hasta la próxima versión regular de corrección de errores.
También las grandes distribuciones se han pronunciado. Hemos revisado los avisos oficiales:
| Proveedor | Estado según el aviso oficial |
|---|---|
| Ubuntu | USN-8948-1 para 22.04, 24.04, 26.04 y 26.10; USN-8948-2 para 14.04 a 20.04 mediante Ubuntu Pro |
| Debian | Paquetes corregidos para bookworm (php8.2, DLA-4848-1) y trixie (php8.4, DSA-6574-1) |
| Red Hat | Boletín RHSB-2026-013 para RHEL 7 a 10; algunas actualizaciones disponibles, otras en preparación |
Red Hat clasifica CVE-2026-109618 con una puntuación propia como «Important» y lo justifica con una mayor complejidad del ataque. Es un método de valoración distinto del del proyecto PHP y no es motivo para aplazar la actualización.
Cómo valoran la situación las autoridades
El BSI ha declarado el nivel de alerta 3 / naranja. Recomienda la actualización inmediata y, si no es posible hacerla enseguida, desconectar temporalmente de la red los servidores web afectados. El BSI contaba con una explotación rápida y a gran escala. Qué significa la clasificación lo explica la página Qué recomienda el BSI sobre PHP2Shell.
Según los informes, CERT-EU considera posible que estén afectadas las versiones desde PHP 5 y aconseja aislar las aplicaciones accesibles públicamente si no pueden parchearse a tiempo. CERT-Bund (el CERT del Gobierno alemán) y la empresa de seguridad Huntress también han alertado.
La recomendación de desconectar en caso necesario se aplicó de forma visible. Según los medios, la ciudad de Maguncia retiró de la red de forma preventiva su portal web central; las oficinas siguieron localizables por teléfono y por correo electrónico. En Hesse, según hessenschau, estuvieron temporalmente fuera de línea páginas del Gobierno regional, de la BKA (Oficina Federal de Policía Criminal alemana) y de las ciudades de Kassel y Wiesbaden. La Cancillería del Estado no comunicó ningún ataque y las páginas volvieron a estar accesibles por la tarde. Otros municipios, universidades y clínicas actuaron de forma parecida, según los informes.
Qué se sabe de los ataques
Aquí es especialmente importante la separación entre observación y confirmación.
- Observado: según los medios, el 17 de octubre hubo un primer intento de ataque, que observó Amazon. Cloudflare y Patchstack informaron de intentos de ataque; Cloudflare observó además patrones de ataque modificados.
- Reproducido: watchTowr reprodujo CVE-2026-109618 según los informes, según sus propias indicaciones.
- No confirmado: el BSI inicialmente no comunicó explotaciones exitosas confirmadas de forma generalizada. Huntress no vio ataques en los entornos de sus socios en el momento de su aviso.
- Desconocido: no hay indicadores de compromiso publicados ni confirmados. Quien quiera comprobar si un servidor está afectado debe fijarse en patrones de comportamiento.
Sobre la magnitud circulan dos cifras. Los investigadores de Unit 42 de Palo Alto Networks llegaron a más de 22,6 millones de instancias potencialmente vulnerables accesibles desde la red. CybelAngel cita unos 2,24 millones de hosts PHP accesibles, de los cuales, según su propio análisis, el 59 por ciento en versiones sin corrección oficial próxima. Ambas miden cosas distintas y no son directamente comparables. Una clasificación la ofrece el artículo Cómo interpretar las cifras.
Qué sigue abierto
Tres preguntas determinan las próximas semanas:
- Versiones antiguas: una gran parte de las instalaciones de PHP accesibles funciona, según los análisis citados, en ramas sin corrección oficial. Si las ofertas comerciales de soporte a largo plazo cubren PHP2Shell debe confirmarlo por escrito el proveedor en cada caso.
- Actualizaciones incompletas: los paquetes nuevos solo surten efecto cuando se han reiniciado todos los procesos de PHP. Red Hat advierte expresamente de que una simple recarga no basta.
- El tiempo antes del parche: entre el 17 y el 21 de octubre hubo servidores vulnerables mientras ya había intentos de ataque en curso. Un parche no demuestra que en ese tiempo no pasara nada.
Conserve los registros del servidor web y de PHP desde el 20 de octubre, como recomienda la prensa especializada. Sin registros, la pregunta abierta más importante para su servidor ya no podrá responderse después.
Qué deberían revisar ahora los administradores
Para la propia valoración de la situación bastan cuatro puntos de revisión por servidor: ¿está PHP en una versión corregida o en un backport confirmado? ¿Llevan todos los procesos en ejecución desde la actualización? ¿Está session.upload_progress.enabled desactivado en el servidor mientras esté pendiente el aviso de CVE-2026-115560? ¿Hay anomalías desde el 17 de octubre?
Para el último punto ayuda la página ¿Ya estoy comprometido?. Un proceso del servidor web que lanza una shell, archivos PHP nuevos en las carpetas de subida, tareas cron o claves SSH desconocidas son señales de advertencia que justifican una investigación más detallada.
¿Cómo ayuda PHP SOS en concreto?
- Valoramos el nivel de parcheo de cada servidor a partir del estado de los paquetes, el registro de cambios y las horas de inicio de los procesos.
- Donde no hay parche disponible, aplicamos las medidas provisionales de php.net y aclaramos el camino hacia la versión compatible.
- Conservamos los registros desde el 20 de octubre y buscamos indicios del periodo anterior al parche.
- Con la ayuda inmediata ante PHP2Shell reunimos estos pasos para las empresas que necesitan claridad rápido.
Preguntas frecuentes
¿Se está explotando ya PHP2Shell de forma activa?
Cloudflare y Patchstack informaron de intentos de ataque. El BSI (Oficina Federal alemana para la Seguridad de la Información) inicialmente no comunicó ataques exitosos confirmados de forma generalizada. Huntress no vio ataques en los entornos de sus socios en el momento de su aviso.
¿Ha pasado el peligro tras los parches?
No. Los parches solo protegen a los servidores que los han instalado y han reiniciado todos los procesos de PHP. Los sistemas con PHP 8.1 y anterior siguen siendo vulnerables sin un backport confirmado, y un parche no elimina el software malicioso introducido antes.
¿Por qué estuvieron fuera de línea las webs de las autoridades?
Según los medios, entre otras la ciudad de Maguncia y varios organismos de Hesse desconectaron sus sitios web de forma preventiva. Esto corresponde a la recomendación del BSI para los servidores que no pueden actualizarse de inmediato. Una desconexión no significa que haya habido un ataque.
¿Existen indicadores para reconocer un ataque de PHP2Shell?
Hasta ahora no hay indicadores de compromiso (Indicators of Compromise) publicados ni confirmados. La detección se basa en el análisis del comportamiento, por ejemplo procesos de PHP que lanzan una shell o archivos PHP nuevos en las carpetas de subida.