En resumen: Entre los hechos comprobados de PHP2Shell están los dos números CVE, la puntuación CVSS v4.0 9,2, las versiones de PHP corregidas y las medidas provisionales de php.net. También está comprobado el nivel de alerta naranja del BSI (Oficina Federal alemana para la Seguridad de la Información). No están comprobados una puntuación CVSS 10, ataques exitosos de forma generalizada ni una lista de indicadores de detección. Quien separa estos tres niveles toma mejores decisiones.
Por qué hace falta una verificación de hechos sobre PHP2Shell
Pocas vulnerabilidades de los últimos años han generado tantos titulares tan deprisa. Ya antes de que el equipo de PHP publicara las actualizaciones el 21 de octubre de 2026, circulaban, según los informes, mensajes de foro, capturas de pantalla y supuestos detalles. Después llegaron los avisos de las autoridades, los blogs de los fabricantes, los recuentos de servidores expuestos y una avalancha de consejos.
Para los responsables de los sistemas esto significa que no todas las cifras ni todos los consejos tienen la misma calidad. Una parte procede de fuentes primarias, otra de información periodística seria y otra de la especulación. Este artículo clasifica lo que puede usar como dato fiable para sus decisiones. Los fundamentos de la vulnerabilidad los explica la página ¿Qué es PHP2Shell?.
Qué peso tiene cada fuente
Una jerarquía sencilla ayuda a leer cualquier aviso:
- php.net: el proyecto PHP es la fuente primaria de los números CVE, las puntuaciones, los modos de ejecución afectados, las versiones corregidas y las medidas provisionales. Cómo trata el proyecto los avisos de seguridad en general lo describe nuestro artículo sobre el proceso de seguridad de PHP.
- Autoridades: el BSI aporta la valoración de la situación en Alemania y recomendaciones de actuación; CERT-EU y CERT-Bund (el CERT del Gobierno alemán) las complementan.
- Distribuciones y proveedores: Debian, Ubuntu, Red Hat, los proveedores de alojamiento y los servicios de plataforma solo se pronuncian de forma vinculante sobre sus propios paquetes y servicios.
- Empresas de seguridad: Cloudflare, Unit 42, CybelAngel y otras informan a partir de sus propias mediciones. Son valiosas, pero cada una con su propio método.
- Medios y redes sociales: buenos en rapidez, débiles en los detalles. Lo que dicen necesita confirmación en un nivel superior.
Comprobado, informado, sin pruebas: el resumen
La tabla siguiente clasifica las afirmaciones más frecuentes. «Comprobado» significa: fuente primaria o autoridad. «Informado» significa: procedente de medios o de datos de los fabricantes, sin confirmación independiente.
| Afirmación | Clasificación | Base |
|---|---|---|
| Dos vulnerabilidades, CVE-2026-109618 y CVE-2026-109619 | comprobado | php.net |
| Puntuación CVSS v4.0 9,2, crítica | comprobado | php.net |
| Puntuación CVSS 10 | no sostenible | según los informes, de un mensaje de foro previo al aviso |
| Corregido en 8.5.12, 8.4.27, 8.3.36, 8.2.35 | comprobado | php.net |
| mod_php con el mayor riesgo, exploit demostrado antes del código de la aplicación | comprobado | php.net |
| Afectadas casi todas las versiones hasta PHP 5.4 | informado | prensa especializada |
| Primer intento de ataque el 17 de octubre | informado | medios, citando a Amazon |
| Más de 22,6 millones de instancias expuestas | informado | Unit 42, según TechTarget |
| Ataques exitosos de forma generalizada | sin pruebas | según el BSI, inicialmente no conocidos |
| Indicadores de compromiso confirmados | no existen | sin publicación |
| Las medidas provisionales protegen por completo | falso | php.net las califica expresamente de incompletas |
Llama la atención lo pronto que algunas cifras cobran vida propia. La puntuación 10.0 del mensaje de foro seguía apareciendo días después en distintas publicaciones, aunque el equipo de PHP hacía tiempo que había publicado 9,2.
Dónde está de verdad la incertidumbre
La mayor pregunta abierta no es técnica, sino temporal: ¿qué ocurrió entre el primer intento de ataque informado y el parche en cada servidor? A eso no hay una respuesta general. Cloudflare y Patchstack informaron de intentos de ataque, y watchTowr, según sus propias indicaciones, reprodujo CVE-2026-109618. Huntress, por su parte, no vio ataques en los entornos de sus socios en el momento de su aviso.
Estas afirmaciones no se contradicen. Describen fragmentos distintos: un gran servicio de proxy, una empresa de seguridad de plugins, un equipo de investigación y una empresa con su propia base de clientes. De ahí no resulta una imagen de conjunto.
Algo parecido ocurre con la pregunta de qué versiones están afectadas. Para 8.2 a 8.5 la situación es clara. Para las ramas anteriores hay backports mínimos del código fuente para 7.4, 8.0 y 8.1, pero no hay versiones oficiales. Lo anterior a eso está afectado, según la prensa especializada, casi por completo. Para su planificación esto apenas cambia nada: un servidor con PHP 8.1 o anterior sin un backport confirmado debe tratarse como vulnerable.
La falta de pruebas de ataques no es una prueba de seguridad. Como no hay indicadores de detección confirmados, un ataque a un servidor concreto solo puede valorarse revisando su comportamiento, no mediante una lista.
Qué deducir de esto para sus servidores
De los hechos comprobados se desprenden pocos pasos claros. De los no comprobados se desprende sobre todo prudencia.
- Comprobar el nivel de parcheo: versión corregida o backport confirmado por el proveedor. El número de versión que se muestra no basta por sí solo.
- Reiniciar todos los procesos de PHP: los archivos nuevos solo surten efecto cuando ya no quedan procesos antiguos en ejecución.
- Conservar los registros desde el 20 de octubre: la prensa especializada lo aconseja para que una comprobación posterior siga siendo posible.
- Buscar indicios: archivos PHP nuevos en las carpetas de subida, tareas cron desconocidas, procesos del servidor web con shell. La página ¿Ya estoy comprometido? le guía en la comprobación.
- Contrastar los consejos: aplique los consejos de foros y redes sociales solo si se pueden remontar a php.net o a una autoridad. Qué recomendaciones perjudican ahora mismo lo recoge el artículo Consejos erróneos y peligrosos sobre PHP2Shell.
Para la comunicación interna sirve la misma separación. Quien presenta a la dirección por separado lo «comprobado», lo «informado» y lo «abierto» evita tanto el alarmismo como la falsa tranquilidad.
¿Cómo ayuda PHP SOS en concreto?
- Situación de sus sistemas: trasladamos los hechos comprobados a sus servidores y separamos en la documentación lo que se ha medido, lo que se ha informado y lo que sigue abierto.
- Parche y justificante: comprobamos el estado de los paquetes y el reinicio de cada servicio de PHP y lo dejamos por escrito.
- Revisión de indicios: conservamos los registros desde el 20 de octubre y buscamos comportamientos anómalos hasta que el incidente quede cerrado y documentado.
- Valoración continua: valoramos para usted las nuevas informaciones antes de que se conviertan en medidas.
El procedimiento lo describe la ayuda inmediata ante PHP2Shell.
Conclusión
PHP2Shell es grave, y eso está bien documentado. Precisamente por eso merece la pena una mirada sobria: las fuentes primarias bastan para todas las decisiones importantes. Lo que circula además suele ser más rápido que preciso. Parchear, reiniciar, conservar los registros y buscar indicios sigue siendo la respuesta, con independencia de la cifra que esté circulando en cada momento.
Preguntas frecuentes
¿PHP2Shell tiene una puntuación CVSS de 10?
No. Según los informes, la cifra 10 procede de un mensaje de foro que circuló antes del aviso oficial. El equipo de PHP puntúa ambas vulnerabilidades con CVSS v4.0 9,2. Aun así, sigue siendo la categoría crítica.
¿Existe una lista de indicadores para reconocer ataques de PHP2Shell?
Hasta ahora no. No hay indicadores de compromiso (Indicators of Compromise) publicados ni confirmados. Quien quiera comprobar si un servidor se vio afectado debe fijarse en comportamientos anómalos, por ejemplo procesos del servidor web que lanzan una shell o archivos PHP nuevos en las carpetas de subida.
¿Qué fuente es la más fiable sobre PHP2Shell?
Para los hechos técnicos, los avisos de php.net; para la valoración de la situación en Alemania, el BSI (Oficina Federal alemana para la Seguridad de la Información). Los medios y los blogs de los fabricantes completan el cuadro, pero deben tratarse como informes y contrastarse con la fuente primaria.
¿Están afectadas de verdad todas las versiones de PHP desde PHP 5?
Está comprobada la situación de las ramas 8.2 a 8.5, para las que hay actualizaciones. Según la prensa especializada, están afectadas casi todas las versiones hasta PHP 5.4; según los informes, CERT-EU consideraba posibles las versiones desde PHP 5. Para versiones anteriores no hay actualizaciones oficiales, por lo que debe tratarlas en cualquier caso como vulnerables.