Amazon detectó ataques activos contra CVE-2026-109618 y CVE-2026-109619 antes del parche de emergencia del 21 de octubre — AWS WAF mitiga parcialmente mientras se actualiza
El 21 de octubre de 2026, el proyecto PHP lanzó parches de emergencia para dos vulnerabilidades críticas de ejecución remota de código en el núcleo del runtime, rastreadas como CVE-2026-109618 y CVE-2026-109619 y nombradas colectivamente PHP2Shell. Ambas recibieron una puntuación CVSS v4.0 de 9.2 (Crítica) y permiten a un atacante no autenticado ejecutar código en un servidor vulnerable. Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Amazon Threat Intelligence detectó explotación activa de PHP2Shell antes de la divulgación pública, lo que confirma que la ventana de exposición no fue teórica: hubo actores que conocían las fallas y las usaban mientras los administradores desconocían su existencia.
Cómo las fallas explotan el procesamiento de multipart/form-data antes de que se ejecute el código de la aplicación
Ambas vulnerabilidades están enraizadas en cómo PHP maneja el procesamiento de solicitudes multipart/form-data — el formato que los navegadores usan para cargas de archivos — antes de que se ejecute el código de la aplicación. CVE-2026-109618 corrompe memoria cuando PHP se queda sin memoria durante el procesamiento de una solicitud. CVE-2026-109619 permite que una solicitud deje datos obsoletos que una solicitud posterior en el mismo proceso worker reutiliza. Ninguna de las dos requiere autenticación ni interacción con el código de la aplicación: el ataque ocurre en la capa del runtime, antes de que el framework o la lógica de negocio tengan oportunidad de validar la entrada.
Esta característica — que la explotación no depende de código vulnerable en la aplicación sino de cómo el intérprete mismo maneja la solicitud — amplifica el alcance del impacto. Cualquier servidor PHP que acepte solicitudes multipart/form-data es potencialmente vulnerable, independientemente de la calidad del código que corre sobre él. El vector de ataque confirmado involucra el campo PHP_SESSION_UPLOAD_PROGRESS, un mecanismo interno de PHP para rastrear el progreso de cargas de archivos, que puede activarse desde una solicitud HTTP sin que la aplicación lo solicite explícitamente.
Por qué AWS WAF mitiga parcialmente pero no cierra la vulnerabilidad
Amazon Web Services publicó reglas de AWS WAF para ayudar a reducir la exposición durante la ventana de parcheo, pero la documentación técnica de AWS es explícita sobre las limitaciones del firewall de aplicaciones web en este escenario. AWS WAF puede bloquear solicitudes que contengan el campo PHP_SESSION_UPLOAD_PROGRESS y puede limitar el tamaño del cuerpo de la solicitud, lo que mitiga el camino de ataque basado en agotamiento de memoria por cuerpo sobredimensionado. Sin embargo, no puede inspeccionar la estructura interna de un cuerpo multipart ni tiene visibilidad sobre la memoria del worker PHP o la configuración del servidor.
El problema más grave es que CVE-2026-109618 puede explotarse mediante amplificación de encabezados: unos pocos kilobytes de encabezados de partes individuales que se expanden en mucha más memoria dentro de PHP. Esta técnica de ataque permanece dentro de los límites de tamaño que AWS WAF puede inspeccionar (entre 8 KB y 64 KB según el servicio y la configuración del web ACL), por lo que el firewall no puede detectarla. Para aplicaciones que aceptan cargas multipart legítimas — formularios de contacto con adjuntos, sistemas de gestión de contenido, plataformas de e-commerce con imágenes de productos — bloquear todo el tráfico multipart/form-data no es una opción viable, lo que deja a esas aplicaciones expuestas hasta que se aplique el parche de PHP.
El impacto en América Latina por la dependencia estructural de PHP en infraestructura web heredada
PHP sigue siendo el lenguaje de backend dominante en una porción significativa de la infraestructura web de América Latina, especialmente en sectores con sistemas heredados: e-commerce de pequeña y mediana escala, portales gubernamentales, plataformas educativas y sitios de medios regionales. La combinación de ciclos de actualización lentos — muchas organizaciones en la región corren versiones de PHP con varios años de antigüedad — y la prevalencia de hosting compartido económico amplifica el riesgo. En hosting compartido, múltiples sitios comparten el mismo proceso worker de PHP, lo que convierte a CVE-2026-109619 (la falla de reutilización de estado obsoleto entre solicitudes) en un vector de ataque lateral: un atacante podría comprometer un sitio y afectar a otros en el mismo servidor.
Brasil y México, los dos mercados con mayor volumen de infraestructura PHP en la región, enfrentan una ventana de exposición extendida porque el parcheo de flotas distribuidas en múltiples proveedores de hosting y nubes públicas requiere inventariar dónde corre PHP, programar ventanas de mantenimiento y probar aplicaciones contra las nuevas versiones. Mientras tanto, la confirmación de explotación activa antes de la divulgación pública sugiere que actores de amenaza ya tienen exploits funcionales en circulación, lo que reduce el tiempo disponible para responder antes de que la explotación masiva se generalice.
Nuestro análisis
PHP2Shell revela un patrón que se repite en vulnerabilidades críticas de runtime: la superficie de ataque no está en el código de la aplicación sino en cómo el intérprete procesa la entrada antes de que la aplicación tenga control. Este tipo de falla — similar a las que afectaron a Log4j en 2021 o a las bibliotecas de deserialización de Java en años anteriores — es especialmente peligrosa porque no hay código vulnerable que auditar ni configuración de aplicación que endurecer. El único control efectivo es actualizar el runtime, lo que en infraestructura distribuida y heterogénea puede llevar semanas.
La detección de explotación activa por parte de Amazon Threat Intelligence antes de la divulgación pública confirma que la ventana de día cero fue real y que actores de amenaza tuvieron acceso anticipado a las fallas. Esto plantea la pregunta de cuántos servidores fueron comprometidos antes del 21 de octubre sin que los administradores tuvieran forma de saberlo. La ausencia de indicadores de compromiso (IoC) públicos en la documentación de AWS y PHP sugiere que la telemetría de detección todavía está en desarrollo o que los vectores de explotación son lo suficientemente variados como para que no haya un patrón de firma único. ¿Qué pasaría si la próxima falla crítica de runtime se explota durante meses antes de que alguien la detecte y publique un parche?