PHP2Shell es el nombre de dos vulnerabilidades críticas de PHP, identificadas como CVE-2026-109618 y CVE-2026-109619. Si un atacante logra explotarlas, podría ejecutar código en un servidor afectado sin necesidad de iniciar sesión. Los parches se publicaron el 21 de octubre de 2026 y empresas de seguridad reportaron intentos de explotación; eso no significa que se hayan confirmado intrusiones en todos los sistemas afectados.
11
14
19
Qué hacen las fallas de PHP2Shell
Las vulnerabilidades están en el propio entorno de ejecución de PHP, no en un sitio web o sistema de gestión de contenidos específico. Red Hat describe una falla relacionada con el manejo de memoria cuando se produce un error durante la lectura de una solicitud; la otra puede dejar un estado interno obsoleto si un error fatal interrumpe la limpieza.
7 En conjunto, estos problemas pueden abrir una vía para la ejecución remota de código: en otras palabras, un atacante podría ejecutar instrucciones en un servidor vulnerable sin autenticarse antes.
11
13
Ambas fallas obtuvieron una puntuación CVSS 4.0 de 9,2, considerada crítica.
4 Entre las posibles consecuencias están la toma de control del servidor, la exposición de datos y la interrupción de servicios. Pero la existencia de las vulnerabilidades no demuestra que todos los sitios que usan PHP hayan sido atacados o comprometidos.
13
Por qué generó una respuesta urgente
Según los reportes, las fallas llevaban años presentes en PHP antes de hacerse públicas.
42 Que hayan permanecido en el software durante mucho tiempo no demuestra que los atacantes las conocieran o las explotaran durante todo ese periodo.
El caso también puso el foco en la investigación de seguridad asistida por inteligencia artificial. Según las informaciones disponibles, Calif y Wiz utilizaron herramientas de IA en sus investigaciones, mientras que OpenAI participó en el trabajo de investigación y divulgación.
34
44 La IA puede ayudar a examinar software, pero el hecho de que haya contribuido al descubrimiento no permite concluir qué tan rápido podrían aprovechar herramientas similares los atacantes ni qué parte lleva ventaja.
Algunos titulares destacaron el uso extendido de PHP —estimado en torno al 70 % de los sitios web—.
20 Esa cifra se refiere a su alcance estimado, no a la cantidad de servidores confirmados como vulnerables o comprometidos. La exposición real depende de la versión de PHP, la configuración y el entorno de cada sistema, además de si ya se aplicó una corrección.
Parches, intentos de ataque y lo que se sabe
El proyecto PHP publicó correcciones el 21 de octubre en las versiones 8.2.35, 8.3.36, 8.4.27 y 8.5.12.
19 Para instalaciones anteriores, conviene consultar los avisos de seguridad del sistema operativo o del proveedor de alojamiento y comprobar si existe un parche verificado o una corrección adaptada. No hay que dar por hecho que está disponible —ni que no lo está— sin verificarlo.
Hay reportes de intentos de explotación. SecurityWeek informó que Amazon detectó un intento el 17 de octubre, cuatro días antes de que se publicaran los parches.
14 Cloudflare también comunicó un fuerte aumento del tráfico que intentaba aprovechar las fallas, con cifras que llegaron a millones en reportes posteriores.
27
38 Esas cifras describen intentos observados, no intrusiones exitosas.
Los análisis no coinciden plenamente sobre la escala de la explotación: algunas fuentes describen intentos activos, mientras que otra evaluó que la explotación masiva parecía menos probable de lo que se había previsto al principio.
3
4 La información disponible no demuestra que se haya producido una ola generalizada de intrusiones exitosas. Conviene tomar en serio los reportes creíbles de actividad maliciosa, sin confundir un escaneo o intento de ataque con la prueba de que un servidor concreto fue vulnerado.
2
3
Qué hicieron organismos y operadores
Algunas organizaciones desconectaron temporalmente servicios públicos mientras respondían al incidente. Los reportes mencionan cierres temporales o tareas de mantenimiento en Japón, Francia, Finlandia y Países Bajos; organismos de Estados Unidos y Europa también instaron a tomar medidas.
18
20
35 Desconectar un sitio puede reducir la exposición durante una respuesta, pero no demuestra que haya sido comprometido.
El material consultado para este artículo no permite confirmar de forma independiente las declaraciones atribuidas al director ejecutivo de Microsoft, Satya Nadella, en un evento celebrado en Colonia, ni su formulación o contexto. Por falta de confirmación fiable, esas declaraciones no deben usarse para explicar la respuesta ni para caracterizar el incidente.
Qué deben hacer los operadores de PHP
- Revisar el entorno de ejecución, no solo la aplicación. PHP2Shell afecta al propio entorno de PHP. Actualizar un CMS o un complemento no demuestra que la instalación subyacente de PHP esté corregida.
13
- Aplicar una corrección verificada. Actualizar a una versión corregida de PHP o seguir las instrucciones del proveedor si ofrece un parche adaptado. Confirmar qué versión está ejecutándose en producción.
19
- Buscar indicios de intrusión. Aplicar el parche corrige la vulnerabilidad, pero no prueba que el servidor nunca haya sido accedido. Revisar los registros pertinentes e investigar actividad sospechosa antes de normalizar el funcionamiento.
- Usar con cautela las medidas temporales. Seguir las recomendaciones vigentes de los responsables de PHP o del proveedor. No confiar en un único cambio de configuración ni en un cortafuegos de aplicaciones web como sustituto de una corrección verificada del entorno de ejecución.
15
27
- Mantener medidas de protección de cuentas. Las contraseñas únicas y la autenticación multifactor ayudan a proteger las cuentas, pero no corrigen una falla que permite ejecutar código en el servidor sin autenticación.
Para los equipos de TI, es importante distinguir entre una vulnerabilidad, un intento de explotación y una intrusión confirmada. Esa diferencia permite actuar con urgencia sin convertir afirmaciones inciertas en conclusiones sobre quién fue vulnerado.