Vulnerabilidades filtradas con antelación: la explotación activa se adelantó cuatro días al parche
El 21 de octubre de 2026, el equipo de mantenimiento de PHP publicó correcciones para dos vulnerabilidades críticas de ejecución remota de código (RCE): CVE-2026-109618 y CVE-2026-109619. Ambas recibieron una puntuación CVSS v4.0 de 9.2. Las versiones oficiales corregidas cubren PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12. De manera excepcional, el equipo de seguridad también proporcionó parches a nivel de código fuente para ramas sin soporte oficial desde hace años, como 7.4, 8.0 y 8.1.
El modelo habitual de divulgación coordinada de vulnerabilidades asume que los parches llegan a los administradores antes de que existan exploits activos en Internet. En el caso de PHP2Shell, ese mecanismo fracasó por completo. Antes del lanzamiento oficial, la firma de seguridad Huntress emitió una alerta pública bajo el título “Leaked Critical PHP Vulnerabilities”, advirtiendo que los detalles técnicos ya circulaban en canales clandestinos. En un movimiento sin precedentes, los mantenedores de PHP publicaron el boletín n.º 509 en php.announce instando a los administradores de sistemas de todo el mundo a prepararse de inmediato. Ars Technica informó sobre este aviso extraordinario, subrayando que la alarma previa de los mantenedores evidenciaba que la situación había escapado a su control.
Los atacantes no esperaron a los parches oficiales. Datadog Security Labs había desarrollado de forma independiente un exploit funcional antes de la divulgación pública. Por su parte, el equipo de inteligencia sobre amenazas de AWS confirmó mediante su red de señuelos MadPot que se registraron intentos reales de explotación desde el 17 de octubre, cuatro días antes de la publicación oficial. Los atacantes ya sondeaban servidores expuestos mucho antes de que los defensores recibieran las advertencias institucionales.
La firma de seguridad Sansec emitió una advertencia urgente: quince minutos después del lanzamiento del parche comenzarían ataques automatizados a escala global. El 21 de octubre, Datadog citó datos de Patchstack confirmando que múltiples ataques reales y escaneos indiscriminados ya se extendían por la red. Atacantes y defensores accedieron al código del parche al mismo tiempo, reduciendo a cero el margen habitual de análisis y actualización de los administradores.
Figura: Alcance del impacto y cadena de ataque de PHP2Shell publicados por Datadog Security Labs. Fuente: Datadog Security Labs
La petición no llega al código: la fase de limpieza del intérprete entrega la shell
La mayoría de arquitecturas de seguridad en aplicaciones web concentran sus esfuerzos en pasarelas de autenticación, control de rutas e inspección de código. Sin embargo, en las pruebas técnicas de Datadog Security Labs, PHP2Shell eludió todas las capas de defensa de la aplicación. En un entorno configurado con PHP 8.5.11, Apache prefork con mod_php y parámetros estándar (memory_limit=16M, post_max_size=64M), un atacante no autenticado podía tomar el control absoluto del servidor enviando una única petición HTTP POST manipulada.
El fallo se dispara en el motor de tiempo de ejecución en lenguaje C de PHP. Al recibir la petición maliciosa, el servidor experimenta de inmediato un error de análisis sintáctico antes de transferir el flujo de control a cualquier script de la aplicación. Durante la rutina de limpieza interna de PHP para peticiones fallidas, el intérprete ejecuta los comandos del sistema inyectados en la carga útil. Incluso en servidores que alojan únicamente un script elemental que devuelve texto fijo, la máquina queda completamente comprometida en el instante en que falla el análisis.
Este vector de ataque afecta a casi todos los modelos de despliegue modernos. De acuerdo con los informes de Huntress y los registros de incidentes, la vulnerabilidad alcanza desde PHP 5 hasta PHP 8. Los entornos afectados incluyen Apache mod_php, php-cgi tradicional, el estándar de alta concurrencia PHP-FPM, FrankenPHP y LiteSpeed. La autenticación a nivel de aplicación resulta inútil, ya que la ejecución ocurre antes de que el script comience a procesarse.
Figura: Flujo de llamadas donde la rutina de limpieza tras el error de análisis ejecuta comandos del sistema. Fuente: Datadog Security Labs
Incremento del contador antes de asignar memoria: análisis del doble CVE
Ambas vulnerabilidades explotan debilidades estructurales distintas durante el ciclo de vida de la petición HTTP. El fallo en CVE-2026-109618 radica en que la rutina de limpieza tras un fallo de asignación de memoria confía erróneamente en estructuras de datos no inicializadas. El punto crítico se ubica en la función principal del motor Zend _zend_hash_str_add_or_update_i(). Al insertar claves en una tabla hash, la función incrementa el contador de elementos antes de reservar memoria para el nombre de la clave.
Si la reserva de memoria para la clave supera el umbral de memory_limit, el motor Zend genera un error fatal inmediato. En ese instante, el contador ya incluye el nodo de la cubeta (bucket), el cual contiene bytes residuales no inicializados procedentes de operaciones previas en el heap. La rutina de limpieza posterior interpreta estos datos residuales como variables válidas e intenta destruirlos. Al manipular estos residuos de memoria, los atacantes logran desviar el flujo hacia la invocación de system(). Incluso en PHP 8.5.12, el contador se sigue incrementando antes de la reserva; la corrección oficial modificó el flujo de gestión de errores para que las asignaciones fallidas no dejen entradas a medio inicializar.
La otra vulnerabilidad, CVE-2026-109619, aprovecha la persistencia de estados entre peticiones consecutivas en procesos worker. En PHP 8.5 bajo mod_php, los volcados de seguimiento tras errores fatales pueden desembocar en ejecución arbitraria de comandos. En la gestión de subidas de archivos, los estados de sesión o decodificadores que sobreviven a errores fatales se propagan a peticiones posteriores. La directiva session.upload_progress.enabled, activada por defecto en muchos entornos, opera en segundo plano sin necesidad de que la aplicación llame a session_start().
Para explotar con éxito CVE-2026-109619, las peticiones maliciosas consecutivas deben ser atendidas por el mismo proceso worker. En arquitecturas basadas en grupos de procesos o entornos de alto tráfico, la probabilidad de impacto individual se diluye, pero esto representa solo un factor estadístico que no reduce la gravedad del problema.
Figura: Mecanismo de persistencia de estados y memoria contaminada entre peticiones en procesos worker. Fuente: Datadog Security Labs
Desactivar el progreso de subida no basta: los ajustes de configuración no reparan los fallos de memoria
Tras publicarse los fallos, en la comunidad se popularizó la recomendación temporal de fijar session.upload_progress.enabled = 0. Este ajuste genera una falsa sensación de protección. Solo mitiga ciertas vías de entrada relacionadas con CVE-2026-109619, pero deja completamente desprotegido al sistema frente al fallo de asignación de memoria de CVE-2026-109618. Mientras no se corrija el defecto en la gestión de memoria, desactivar el progreso de subida no elimina la amenaza.
El equipo de PHP propuso pautas de mitigación provisionales muy estrictas. Para CVE-2026-109618, se recomienda configurar de forma obligatoria memory_limit = -1. Al mismo tiempo, los administradores deben limitar estrictamente el tamaño del cuerpo de las peticiones en el proxy inverso y aplicar límites de memoria mediante cgroups a nivel de contenedor. Se desaconseja de forma expresa el uso de límites por proceso como RLIMIT_AS o RLIMIT_DATA, ya que estas cuotas provocan precisamente los fallos de asignación de memoria que necesita el exploit.
Para CVE-2026-109619, además de desactivar el seguimiento de subida, en entornos con PHP 8.5 se debe fijar fatal_error_backtraces = 0. Todas estas configuraciones deben cargarse antes de que PHP comience a procesar peticiones, lo que exige reiniciar cada uno de los procesos worker. El CERT-EU aconsejó en su boletín 2026-018 aislar de la red aquellas aplicaciones que no puedan actualizarse de inmediato. Datadog recomienda además bloquear las peticiones anómalas en el proxy inverso o en el perímetro de red.
Liquidar 40 años de deuda técnica: actualizar el entorno de ejecución es la única defensa
Al analizar el desarrollo del incidente PHP2Shell, lo que quedó destruido no fue únicamente el parser de PHP, sino el paradigma tradicional de respuesta: el proveedor publica el parche, emite el aviso y los administradores actualizan con calma. La filtración previa y los cuatro días de ataques en la sombra liquidaron cualquier margen de maniobra. Atacantes y defensores obtuvieron los parches a la vez, y las campañas automáticas globales comenzaron pocos minutos después de la difusión pública.
IEEE Spectrum resumió la situación con contundencia: la IA está obligando al sector a liquidar 40 años de deuda técnica acumulada. PHP2Shell ilustra este dilema a la perfección: incrementar el contador antes de asignar la memoria era una práctica que nadie había cuestionado durante décadas. Incluso la solución en PHP 8.5.12 se limitó a parchear la gestión de errores circundante en lugar de rediseñar el orden del contador.
Los administradores que sospechen haber sido blanco de ataques deben vigilar tres señales principales: un aumento abrupto de errores por agotamiento de memoria durante la inicialización de peticiones, envíos de formularios inusualmente grandes con nombres de campo anómalos, y procesos shell secundarios generados de forma inesperada bajo el usuario del servidor web. Estas alertas indican intentos activos de vulnerar el intérprete.
Cuando el tiempo de respuesta se reduce a cero, los cambios de configuración son meros parches temporales. El filtrado en proxys inversos puede frenar escaneos genéricos, pero no soluciona el defecto intrínseco del intérprete. Reemplazar cuanto antes los entornos de ejecución vulnerables en cada entorno de producción es la única opción real para los defensores.
Enlaces de referencia:
- Informe de análisis de vulnerabilidades de Datadog Security Labs
- Comunicados oficiales de seguridad de PHP y boletín php.announce n.º 509
- Informe de inteligencia sobre amenazas de Huntress
- Registro de observaciones de AWS Security Blog
- Reportaje especial de Ars Technica
- Boletín de seguridad 2026-018 de CERT-EU
- Análisis en profundidad de IEEE Spectrum
