Dos vulnerabilidades críticas de PHP pueden permitir la ejecución de código sin autenticación, y Amazon afirma que detectó un aparente intento de explotación cuatro días antes de que se hicieran públicas.
Cómo ponen en riesgo los servidores estas vulnerabilidades
Las vulnerabilidades, CVE-2026-109618 y CVE-2026-109619, se conocen en conjunto como PHP2Shell y afectan al núcleo del entorno de ejecución de PHP. Una de ellas hace que una solicitud agote la memoria mientras PHP prepara datos internos; después, el proceso de limpieza puede gestionar esos datos de forma incorrecta. La otra puede dejar un estado interno obsoleto que apunta a memoria ya liberada y que podría ser utilizado por una solicitud posterior procesada por el mismo proceso de trabajo.
PHP señala que mod_php de Apache es la configuración de mayor riesgo, porque una solicitud sin autenticación puede desencadenar una explotación antes de que se ejecute el código de la aplicación. Los investigadores también demostraron que era posible ejecutar código a través de rutas de aplicaciones PHP-FPM. PHP afirma que todas las instalaciones que atienden solicitudes web están en riesgo, incluidas PHP-FPM, mod_php de Apache, php-cgi, FrankenPHP y LiteSpeed.
Qué debe actualizarse
Cambiar la aplicación de un sitio web o su sistema de gestión de contenidos no es suficiente: las vulnerabilidades están en el propio PHP, por debajo de programas como WordPress o Drupal. Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. PHP ya no ofrece soporte para la versión 8.1 ni para las anteriores, por lo que las organizaciones que las utilizan deben comprobar si su proveedor de sistema operativo o de soporte a largo plazo ofrece una adaptación del parche, o migrar a una versión con soporte.
Cloudflare estima que PHP se ejecuta en casi el 70 % de los sitios web. Esa cifra corresponde a la prevalencia estimada del lenguaje, no al número de sistemas vulnerables o comprometidos. Un ataque exitoso podría dar a un intruso los privilegios del servidor web y permitirle robar datos, interrumpir servicios o usar el servidor para acceder a otros sistemas de la red.
Por qué tardaron las correcciones
La PHP Foundation afirma que durante una auditoría de seguridad externa realizada en 2024 aparecieron indicios del problema de falta de memoria, pero que en ese momento no se había encontrado una vía concreta de ataque. Las correcciones en la gestión de memoria del núcleo pueden conllevar riesgos: los responsables del mantenimiento señalaron que algunas soluciones posibles podían romper la compatibilidad, reducir el rendimiento o exigir cambios en el amplio ecosistema de extensiones de PHP. OpenAI afirma que Calif utilizó su modelo GPT-5.6 Sol para ayudar a encontrar una vulnerabilidad crítica, mientras que Wiz descubrió y notificó ambas de forma independiente. Los responsables del mantenimiento de PHP lideraron las correcciones.
Un calendario de publicación bajo presión
Los identificadores CVE aparecieron en internet el 20 de octubre, antes de que hubiera parches disponibles. PHP adelantó la publicación prevista al 21 de octubre y dijo que podía publicar antes si se filtraban detalles o aparecían indicios de explotación activa. Más tarde, la PHP Foundation afirmó que Chainguard publicó imágenes de contenedor con los parches más de seis horas antes de la publicación coordinada, lo que podría haber dado tiempo a los atacantes para estudiar la corrección. El director ejecutivo de Chainguard defendió la decisión como respuesta a los informes sobre explotación activa.
Qué dicen los informes sobre los ataques
Amazon afirma que su red de honeypots MadPot registró un aparente intento de explotación de PHP2Shell el 17 de octubre, cuatro días antes de que se hiciera pública la vulnerabilidad. Amazon desconoce cómo obtuvo el actor la información sobre la explotación. La empresa informó de más intentos antes y después de la publicación del 21 de octubre, pero dijo que no ha determinado si los primeros habrían funcionado contra sistemas reales. En su alerta del 21 de octubre, CISA señaló que no había observado explotación hasta el momento de su publicación. Los intentos no prueban que se hayan producido intrusiones exitosas, y los informes describen observaciones realizadas en momentos distintos.
PHP puede estar oculto en contenedores, dispositivos, plataformas de alojamiento u otros productos, lo que dificulta su localización. CISA instó a las organizaciones a inventariar sus sistemas, dar prioridad a los servidores accesibles desde internet y desconectar los servicios basados en PHP si no pueden actualizarlos rápidamente. Un cortafuegos de aplicaciones web puede ofrecer protección temporal, pero Cloudflare afirma que no sustituye la actualización de PHP y señala que los atacantes han modificado las cargas útiles para probar las defensas.
Qué deben hacer ahora los equipos de defensa
Amazon afirma que la explotación está ahora muy extendida e insta a las organizaciones a tratar como urgentes las correcciones críticas para los sistemas accesibles desde internet, en lugar de depender de calendarios de aplicación de parches de una semana. Los equipos de defensa deben localizar todos los entornos de ejecución de PHP, verificar que se haya corregido el entorno —no solo la aplicación— y revisar los registros en busca de actividad sospechosa. Como el primer intento observado por Amazon se produjo antes de la advertencia pública, las organizaciones no deben suponer que el riesgo empezó el día en que se divulgó la vulnerabilidad.