El 22 de octubre se publicaron dos vulnerabilidades críticas en PHP, conocidas en conjunto como PHP2Shell: CVE-2026-109618 y CVE-2026-109619. Las dos tienen un puntaje CVSS de 9,2, permiten ejecutar código de forma remota sin autenticación y afectan el manejo de memoria de muchas versiones de PHP, el lenguaje que sostiene buena parte de la web. La reacción fue inmediata: en Europa y otras regiones, organismos de gobierno y empresas sacaron de línea portales y aplicaciones críticas mientras corrían a aplicar los parches.
Apagar un sitio compra tiempo, pero tiene un costo enorme para el negocio. La buena noticia es que hay otra forma de cubrir esa ventana: el virtual patching. En esta nota te cuento qué es PHP2Shell, por qué es tan difícil de contener y cómo VMware vDefend y Avi WAF permiten protegerte sin apagar tus aplicaciones.
En resumen
- PHP2Shell son dos vulnerabilidades críticas de PHP (CVSS 9,2) que permiten ejecutar código antes de que corra la lógica de la aplicación. Validar las entradas en el código no alcanza.
- Broadcom publicó firmas IDS/IPS para vDefend y reglas para Avi WAF que bloquean la explotación en la red, sin tocar el código ni apagar el servicio.
- La microsegmentación y la protección avanzada de vDefend contienen el daño si una aplicación sin proteger igual es comprometida. Según Broadcom, vDefend y Avi no están afectados por estas vulnerabilidades.
Qué es PHP2Shell y por qué preocupa tanto
PHP2Shell rompe algunos supuestos básicos sobre cómo un servidor web maneja la memoria de cada pedido cuando algo falla:
- CVE-2026-109618, corrupción de memoria por falta de memoria (OOM). Se dispara cuando un pedido supera el límite de memoria de PHP, por ejemplo, durante la carga de archivos. La interrupción deja datos internos a medio inicializar, y las rutinas de limpieza terminan procesando memoria que controla el atacante. Resultado: ejecución de código sin autenticación, antes de que la aplicación llegue a correr.
- CVE-2026-109619, estado global obsoleto. Ciertos errores fatales dejan punteros globales apuntando a memoria que ya fue liberada. El siguiente pedido que atiende ese mismo proceso trabaja sobre esa memoria inválida.
Lo crítico para un equipo de seguridad es esto: como la corrupción ocurre antes de que se ejecute el código de la aplicación, las validaciones de entrada que hacen los desarrolladores no sirven como defensa. Hay que frenar el ataque antes de que llegue al servidor PHP.
El problema de fondo: no podés parchear lo que no sabés que existe
La razón principal por la que tantas organizaciones apagaron sus sitios es un problema de visibilidad. Con los años, PHP quedó embebido en portales heredados, appliances de terceros, microservicios internos y dashboards en contenedores que no siempre figuran en el inventario. En plena crisis, los equipos de seguridad se encontraron frente a tres preguntas sin respuesta rápida:
- ¿Dónde están corriendo instancias de PHP vulnerables en toda nuestra infraestructura?
- ¿Cuáles están expuestas a Internet y cuáles solo a la red interna?
- ¿Cómo priorizamos los parches sin cortar la operación del negocio?
Si la única herramienta es el parche, la decisión es binaria: quedar expuesto a los escaneos automatizados, que con IA aparecen en horas, o apagar el servicio.
Virtual patching: proteger sin apagar
El virtual patching consiste en aplicar un control de red que bloquea la explotación de una vulnerabilidad sin modificar ni apagar la aplicación vulnerable. La protección es inmediata, y el parche definitivo se prueba e instala con calma en una ventana de mantenimiento.
Cómo frenar PHP2Shell en cuatro capas
Broadcom publicó una guía para protegerse con VMware vDefend y Avi Load Balancer. La resumimos en cuatro capas que se complementan:
1. Avi WAF: descubrir y bloquear en el balanceador
Avi WAF analiza el tráfico HTTP/S en vivo y, a partir de encabezados como Server y X-Powered-By, ayuda a identificar qué aplicaciones corren versiones vulnerables de PHP. Sobre esa base, permite aplicar parches virtuales en minutos: inspecciona la estructura de los pedidos, los encabezados multipart y el largo de los campos, y descarta el exploit antes de que llegue al servidor. También normaliza los pedidos, para que no se escapen ataques ofuscados con doble codificación o base64.
Las reglas que recomienda Broadcom dentro de la política de Avi WAF son:
| Reglas CRS | Qué controlan |
|---|---|
| 920170 y 920180 | Anomalías en pedidos multipart |
| 920370 y 920380 | Límites de encabezados y argumentos, para evitar agotar la memoria |
| 932100 a 932200 | Ejecución remota de comandos, como invocaciones a /bin/sh |
| 933100 a 933190 | Ataques a aplicaciones PHP |
A eso se suman las reglas de parche virtual específicas para estos CVE, en modo de bloqueo, publicadas en el artículo 460068 de la base de conocimiento de Broadcom, y la reputación de IP de Avi para bloquear tráfico de direcciones maliciosas.
2. vDefend Gateway Firewall con descifrado TLS e IDS/IPS
Como los ataques llegan cifrados por HTTPS, hay que descifrar el tráfico en algún punto de control para inspeccionarlo. El Gateway Firewall de vDefend, con inspección TLS en los gateways Tier-0 y Tier-1, cumple ese rol tanto para el tráfico que entra desde Internet como para el que se mueve entre zonas internas. Si ya usás las redes NSX de VMware Cloud Foundation, no hace falta cambiar la arquitectura: los Edge Nodes ya están desplegados y alcanza con habilitar las políticas de inspección TLS.
Una vez descifrado el tráfico, el motor IDS/IPS aplica las firmas que publicó el equipo de investigación de amenazas de VMware:
- Bloqueo de CVE-2026-109618: firmas 1156209, 1156228, 1156229, 1156230 y 1156231.
- Bloqueo de CVE-2026-109619: firmas 1156232 y 1156235.
- Detección en modo informativo, para que el SOC vea patrones sospechosos y reconocimiento temprano: firmas 1156210, 1156233 y 1156241.
3. Microsegmentación con el firewall distribuido
El virtual patching frena los ataques conocidos, pero siempre puede haber una aplicación que nadie tenía en el inventario. Ahí entra el firewall distribuido de vDefend, que corre en el hipervisor junto a cada carga de trabajo. Si un atacante logra instalar una web shell en un servidor PHP, la microsegmentación le impide escanear la red o llegar a las bases de datos, las APIs internas y el Active Directory, y bloquea las conexiones salientes no autorizadas.
4. Protección avanzada contra lo que viene después
vDefend ATP agrega análisis de comportamiento: los archivos sospechosos que suben o ejecutan los procesos web se analizan en un sandbox dentro de tu datacenter, y la detección y respuesta de red (NDR) bloquea las conexiones de comando y control (C2) y los reverse shells de un proceso PHP comprometido.
| Capa | Componente | Qué hace |
|---|---|---|
| Aplicación web | Avi WAF | Descubre instancias de PHP y bloquea el exploit en el balanceador |
| Gateway y TLS | vDefend Gateway Firewall + IDS/IPS | Descifra el tráfico y aplica las firmas de PHP2Shell |
| Contención | vDefend DFW | Aísla las aplicaciones vulnerables y frena el movimiento lateral |
| Post-explotación | vDefend ATP | Analiza archivos en sandbox y bloquea C2 y reverse shells |
Qué hacer hoy
- Inventariá tus aplicaciones PHP, incluidas las que no son evidentes: appliances, portales heredados y microservicios en contenedores. El tráfico real que ve Avi es un buen punto de partida.
- Activá las firmas IDS/IPS y las reglas de Avi WAF. Si tenés dudas sobre falsos positivos, empezá en modo de detección unas horas y pasá a bloqueo.
- Revisá la microsegmentación de los servidores PHP: no deberían poder hablar con bases de datos, APIs o Active Directory más allá de lo estrictamente necesario.
- Instalá los parches oficiales de PHP en una ventana de mantenimiento, después de probarlos. El virtual patching te da tiempo, no reemplaza al parche.
- Mirá las alertas de las firmas informativas para detectar reconocimiento o intentos de explotación.
Cómo te ayudamos en Wetcom
En Wetcom acompañamos a nuestros clientes en las primeras horas de un incidente como este: relevamos dónde corre PHP, activamos y ajustamos las firmas de vDefend y las reglas de Avi WAF, y revisamos la microsegmentación de las aplicaciones expuestas. Con nuestro servicio de Networking & Security lo operamos 7×24, y ante un incidente crítico Insane Support escala directo con Broadcom. Si un ataque ya ocurrió, nuestro equipo de Ransomware Incident Response ayuda a contenerlo y a recuperar la operación.
¿Tenés aplicaciones PHP expuestas y no sabés si están protegidas? Escribinos y lo revisamos con vos.
Preguntas frecuentes
¿Qué aplicaciones pueden estar afectadas?
Cualquier aplicación que corra sobre una versión vulnerable de PHP: portales corporativos, sitios en WordPress, Drupal o Magento, appliances de terceros y microservicios. Consultá con cada proveedor si su versión de PHP está afectada y cuándo publica el parche.
¿El virtual patching reemplaza al parche?
No. Bloquea la explotación mientras el parche se prueba y se instala. El parche oficial de PHP se tiene que aplicar igual.
¿Necesito NSX para usar el Gateway Firewall de vDefend?
Sí: el Gateway Firewall corre en los Edge Nodes de las redes NSX de VMware Cloud Foundation. Si ya los tenés, activar la inspección TLS no requiere cambios de arquitectura.
¿vDefend y Avi están afectados por PHP2Shell?
Según Broadcom, VMware vDefend, vDefend Security Services Platform y Avi Load Balancer no están afectados por estas vulnerabilidades.
Fuentes
- Stijn Vanveerdeghem, Broadcom. Neutralizing PHP2Shell: Stopping Critical PHP RCEs with VMware vDefend and Avi WAF, 22 de octubre de 2026.
- NIST, National Vulnerability Database: CVE-2026-109618 y CVE-2026-109619.
- Broadcom Knowledge Base: impacto en vDefend (460110), impacto en Avi (459989) y reglas de virtual patching para Avi (460068).
- Broadcom. Portal de firmas IDS/IPS de vDefend.
- Broadcom. Virtual Patching: Guarding Against a Tsunami of AI-discovered Exploits with vDefend and Avi, abril de 2026.
Lecturas relacionadas
- Por qué vDefend te puede ayudar con la seguridad y el movimiento lateral
- Avi WAAP: cómo proteger tus APIs y aplicaciones web en VMware Cloud Foundation
- Por qué IDS/IPS es crítico para tu ciberseguridad
Sobre el autor
Nicolás Solop es Co-Founder y CTO de Wetcom, Partner Pinnacle de VMware by Broadcom, VMware vExpert y Arquitecto Senior de Infraestructura. Es técnico en Telecomunicaciones y radioaficionado. Lidera la estrategia tecnológica de la compañía y el diseño de plataformas de nube privada, redes y seguridad para empresas de América Latina.