El 20 de octubre se filtraron en Internet detalles sobre dos fallos críticos en PHP antes de que estuvieran listas las correcciones. PHP, el lenguaje de scripting que sustenta una gran parte de la web, adelantó un día el lanzamiento de su parche y lo publicó el 21 de octubre. Las vulnerabilidades, CVE-2026-109618 y CVE-2026-109619 (apodadas «php2shell»), permitían a un atacante ejecutar comandos en un servidor web a través del propio PHP, sin necesidad de iniciar sesión.
Actualiza ahora mismo. La CISA añadió ambas fallas a su lista de vulnerabilidades explotadas el 26 de octubre. Ese consejo es acertado, pero deja un vacío. Esta entrada trata sobre ese vacío.
Los atacantes ya estaban probando la vulnerabilidad antes de que existiera la solución.
Ya se han publicado parches para las versiones de PHP 8.2 a 8.5, y PHP ha anunciado que las versiones 8.1 y anteriores no recibirán actualizaciones. Según una estimación, aún hay unos 884 000 servidores de este tipo en funcionamiento, una cifra aproximada procedente de una única fuente.
Los «honeypots» de Amazon ( servidores señuelo creados para atraer a los atacantes) registraron el primer intento el 17 de octubre, cuatro días antes de que se hiciera pública la información, y para el 21 de octubre Amazon ya estaba detectando numerosos intentos de explotación en el entorno real. Cloudflare detectó los primeros ataques, y el Centro Nacional de Ciberseguridad del Reino Unido advirtió a las organizaciones que actualizaran sus sistemas de inmediato o los desconectaran. Aún no está claro cuántos servidores reales fueron comprometidos. Amazon afirma que desconoce si los intentos que detectó habrían funcionado fuera de un «honeypot».
El 23 de octubre, CrowdStrike y Flare seguían informando únicamente de intentos de exploración y fallidos, muchos de los cuales provocaban un fallo en PHP en lugar de otorgar el control al atacante. Al día siguiente, Adel Karimi, de Perplexity, registró una ejecución remota de código con éxito en un honeypot, y el 26 de octubre la CISA añadió ambas vulnerabilidades a su lista de vulnerabilidades explotadas conocidas, con un plazo federal para la aplicación del parche fijado para el 29 de octubre. La prueba de Karimi utilizó una configuración deliberadamente favorable, por lo que demuestra que la vulnerabilidad funciona, pero no la frecuencia con la que tienen éxito ataques de este tipo.
Todos los fallos llevan ya un tiempo a la vista antes de que alguien los dé a conocer.
Una vulnerabilidad se convierte en noticia el día en que se anuncia, no el día en que aparece. Los propios responsables del mantenimiento de PHP detectaron por primera vez indicios de este problema en una auditoría realizada en 2024, y los atacantes lo aprovecharon antes que el público.
Ya hemos visto este patrón antes. Cuando se produjo el incidente de Log4j en diciembre de 2021, Vectra señaló que el primer indicio de un ataque era difícil de detectar y que lo más prudente era dar por hecho que al menos un servidor del entorno ya había sido comprometido. Es muy probable que otras vulnerabilidades del software que utiliza tu empresa se encuentren hoy en la misma situación: alguien las conoce, pero no se han hecho públicas. La aplicación de parches se ocupa de aquellas de las que te enteras. No sirve de nada para el resto.
Los servidores PHP que echas de menos son los más importantes
PHP ejecuta sitios web de WordPress, Drupal, Joomla y Magento, paneles de control de alojamiento y un montón de software que ni siquiera menciona a PHP. A los servidores que conoces se les aplicarán parches. Los que no conoces son los que los atacantes encuentran primero, porque nadie los vigila.
Los dispositivos y las interfaces de gestión que incorporan PHP son los lugares donde es más probable que un intento de ataque se convierta en una intrusión, y rara vez se supervisan como se hace con los servidores web. Flare, al hacerse eco del informe de un investigador, afirma que algunos incorporan PHP sin aleatorización de direcciones, lo que elimina el principal obstáculo para un atacante. Pregunta a tus proveedores cuáles de sus productos incluyen PHP.
Ningún equipo soluciona todos los problemas el mismo día en que se lanza una corrección. Saber qué servidores están expuestos a Internet y cuáles contienen los datos más valiosos permite reducir la lista de tareas pendientes a una serie de decisiones concretas, entre ellas, qué servicios hay que desactivar hasta que se solucionen los problemas. En cualquier servidor que sospeches que se haya visto afectado, guarda los registros y una instantánea de la memoria antes de reiniciarlo, ya que el reinicio borra los rastros.
¿Qué ocurre cuando se cae un servidor PHP?
Un atacante que consigue ejecutar código a través de PHP no suele necesitar un « malware ». El servidor web ya dispone de un shell, una conexión de red y acceso a los archivos, por lo que puede utilizar las herramientas ya instaladas en la máquina para explorar el sistema, encontrar credenciales y desplazarse de un sistema a otro. No parece haber nada raro, ya que el servidor web sigue realizando sus funciones habituales con comandos ligeramente diferentes. Esa es la primera de las tres lagunas de detección sobre las que escribo: no parece haber nada raro.
Lo que cambia es con quién se comunica el servidor. Un servidor web que lleva años sirviendo las mismas páginas de repente accede a lugares a los que nunca antes había accedido, envía solicitudes a direcciones desconocidas o empieza a comunicarse con sistemas internos. Ese comportamiento se refleja en el tráfico de red, no en el estado de las actualizaciones. Una visión de la red es la forma de ver con qué se conecta realmente un servidor, independientemente de si alguien está supervisando el propio servidor o no.
Lo que puede y no puede ver « Vectra AI »
Vectra AI No le preocupa realmente cuál sea el vector de ataque inicial. Lo que nos interesa es lo que ocurre después.
Hoy el tema es PHP. La semana que viene será otra cosa: otra falla, una llamada al servicio de asistencia técnica, alguien de dentro. Lo que analizamos no depende de qué puerta se haya utilizado. Observamos lo que hace un sistema una vez que el atacante está dentro, por lo que no necesitamos que se conozca la vía de acceso ni que se haya hecho pública la falla. Esto es lo más importante cuando se desconoce el punto de entrada o la vulnerabilidad aún no se ha anunciado.
Identificación de posibles servidores PHP y de la «TI en la sombra»
Uno de los retos a la hora de proteger la infraestructura de PHP es saber, para empezar, dónde se encuentra. Las aplicaciones olvidadas, los servidores no gestionados y la «TI en la sombra» pueden crear puntos ciegos de seguridad, incluso después de que se hayan corregido las vulnerabilidades conocidas.
Vectra AIEl panel de control de visibilidad del servidor PHP (disponible para los clientes que cuenten con un periodo de retención de metadatos de al menos 14 días) ofrece una herramienta de investigación adicional para ayudar a los equipos de seguridad a identificar servidores PHP que podrían haber pasado desapercibidos, utilizando indicadores observados en el tráfico HTTP no cifrado, tales como .php puntos finales y PHPSESSID cookies. De este modo, los analistas pueden investigar si estos servidores también están recibiendo tráfico cifrado procedente del exterior, lo que ayuda a priorizar los sistemas potencialmente expuestos para una investigación más exhaustiva.
El panel de control no pretende ofrecer un inventario completo de los servidores PHP. Solo puede identificar los sistemas que presentan indicadores observables relacionados con PHP, y es posible que el tráfico cifrado o la visibilidad limitada de la red impidan detectar algunos servidores. En cambio, actúa como una herramienta de apoyo a los flujos de trabajo existentes de detección de activos y búsqueda de amenazas, ayudando a los analistas a descubrir posibles casos de «TI en la sombra», investigar la exposición e identificar sistemas que requieran un examen más detallado, incluso después de aplicar los parches.
Reglas de detección para intentos conocidos de explotación de php2shell
Vectra Match incluye ahora reglas para detectar los comportamientos de los atacantes de PHP2Shell cuando se dispone de la visibilidad adecuada del tráfico del atacante. Estas reglas señalan los intentos de explotación conocidos en el tráfico de red cuando dicho tráfico es visible para nosotros, por lo que detectan los intentos en la entrada, mientras que las detecciones mencionadas anteriormente detectan lo que ocurre a continuación. Un intento no equivale a una intrusión. Una coincidencia es un motivo para examinar ese servidor, no una prueba de que haya sido comprometido. Esta función está disponible para todos los clientes de Vectra Match .
Las normas, por número de norma de ET:
- 2072548: ET EXPLOIT PHP php2shell: inyección de sesión por discrepancia en el controlador (CVE-2026-109619)
- 2072549: Vulnerabilidad en PHP «ET EXPLOIT PHP php2shell»: amplificación de encabezados multiparte y error de memoria insuficiente (OOM) (CVE-2026-109618)
- 2072550: Vulnerabilidad en ET PHP «php2shell»: control de archivos vacíos anidados y error de memoria insuficiente (OOM) (CVE-2026-109618)
- 2072551: Vulnerabilidad en PHP «ET EXPLOIT PHP php2shell»: solicitud multiparte fragmentada sin «Content-Length» (CVE-2026-109618)
- 2072552: ET EXPLOIT PHP php2shell: solicitud POST con datos binarios codificados en URL para la corrupción de $_POST (CVE-2026-109618), comentada en el conjunto de reglas, por lo que está desactivada por defecto
- 2072553: Vulnerabilidad en PHP «php2shell»: solicitud multiparte sin «Content-Length» (CVE-2026-109618)
- 2072554: ET EXPLOIT PHP php2shell: inyección de código en el nombre de archivo (CVE-2026-109619)
- 2072555: ET HUNTING PHP: Manipulación de la sesión de progreso de la carga genérica. Se trata de una regla de búsqueda, no de una regla de explotación, por lo que cualquier coincidencia debe considerarse una pista.
- 2072556: Vulnerabilidad en PHP «ET EXPLOIT PHP php2shell»: número excesivo de partes en un envío multiparte (CVE-2026-109618)
- 2072557: Vulnerabilidad en PHP (ET EXPLOIT PHP php2shell): controles insuficientes sobre archivos multiparte vacíos (CVE-2026-109618)
Lo que revela un servidor PHP comprometido sobre tu resiliencia
El antiguo criterio para medir el éxito era si los atacantes lograban entrar. El mejor criterio es hasta dónde llegan. La aplicación de parches, un diseño de red sólido, la división de la red en zonas, el principio del privilegio mínimo y saber qué sistemas albergan los procesos empresariales más importantes: todo ello limita esa distancia. El registro de la red puede mostrar si alguien entró por la puerta antes de que se cerrara y adónde se dirigió a continuación.
En el informe técnico «Mind Your Gaps in the Age of AI-Powered Attacks » se analizan estas tres lagunas de principio a fin.