Dos vulnerabilidades críticas en PHP han abierto una carrera para actualizar servidores y aplicaciones en una parte sustancial de la web. Los fallos, identificados como CVE-2026-109618 y CVE-2026-109619 y agrupados bajo el nombre PHP2Shell, permiten bajo determinadas condiciones ejecutar código de forma remota sin autenticación. La urgencia ha aumentado después de que Amazon Web Services detectara un intento de explotación fechado el 17 de octubre, cuatro días antes de que las vulnerabilidades fueran divulgadas públicamente.
La exposición potencial es inusual por la implantación de PHP. El lenguaje se utiliza en el 69,7% de los sitios cuyo lenguaje de servidor puede identificar W3Techs, una cifra que explica la referencia aproximada al 70% de la web, aunque esto no significa que todos esos sitios sean directamente explotables. WordPress, escrito principalmente en PHP, representa además alrededor del 40% de todos los sitios web.
El proyecto PHP publicó el 21 de octubre las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 para corregir los fallos y ha pedido actualizar inmediatamente. Las versiones anteriores a PHP 8.2 que ya han llegado al final de su ciclo de soporte no recibirán estas correcciones directamente del proyecto, aunque algunos distribuidores y proveedores de soporte prolongado pueden ofrecer parches propios.
La consecuencia para las empresas va más allá de revisar su página corporativa. PHP también está integrado en plataformas de comercio electrónico, sistemas de gestión de contenidos, aplicaciones internas, interfaces administrativas, dispositivos y productos de terceros. ENISA y otros organismos europeos han recomendado localizar todas las aplicaciones que dependen de PHP, priorizar las expuestas a Internet y aislarlas de las redes públicas cuando no sea posible aplicar inmediatamente las actualizaciones.
Dos fallos de memoria permiten ejecutar código sin contraseña
Las dos vulnerabilidades afectan a componentes centrales del motor de PHP relacionados con la gestión de memoria y el tratamiento de errores, utilizados por prácticamente todas las peticiones que procesa el lenguaje.
CVE-2026-109618 se produce durante determinadas situaciones de agotamiento de memoria. Si una petición alcanza el límite configurado en un momento concreto, PHP puede dejar estructuras internas parcialmente inicializadas y tratarlas posteriormente como válidas. En servidores Apache que utilizan mod_php, se ha demostrado la ejecución remota de código con la configuración predeterminada antes incluso de que se ejecute el código de la aplicación.
CVE-2026-109619 responde a un problema diferente pero relacionado. Un error fatal puede dejar referencias internas hacia memoria que ya pertenecía a una petición anterior. Si otro acceso es procesado posteriormente por el mismo trabajador, PHP puede reutilizar ese estado obsoleto. Los investigadores confirmaron un escenario de «use-after-free» y demostraron ejecución remota de código contra una aplicación real con Apache y mod_php.
Ambas vulnerabilidades tienen una puntuación de 9,2 sobre 10 en CVSS 4.0. Google sitúa las versiones afectadas entre PHP 5.4 y PHP 8.5.11 y recomienda migrar como mínimo a PHP 8.2 con las revisiones corregidas correspondientes. Google Cloud también ha advertido de que imágenes de contenedores creadas y mantenidas por cada cliente deben reconstruirse y desplegarse de nuevo para incorporar el runtime actualizado.
El alcance exacto depende de la versión, la arquitectura del servidor y la forma en la que PHP esté integrado. Esto impide equiparar automáticamente la cuota de mercado del lenguaje con el número de máquinas explotables. Sí convierte, sin embargo, la localización de instalaciones antiguas y dependencias indirectas en una prioridad operativa.
AWS detectó actividad cuatro días antes de la divulgación
El episodio adquirió una dimensión adicional cuando AWS informó de que sus sistemas MadPot habían registrado el 17 de octubre un intento de explotación dirigido contra uno de sus señuelos. La actividad procedía de una dirección IP asociada a una red comercial de anonimización.
Amazon considera que las características de la conexión apuntan a un actor malicioso, pero no ha podido determinar cómo obtuvo información sobre los fallos antes de que fueran públicos ni si aquel intento habría funcionado contra un sistema real.
La actividad aumentó antes de levantarse el embargo. AWS identificó varias pruebas de concepto y nuevos intentos entre las 02:00 y las 08:00 UTC del 21 de octubre, procedentes de diferentes infraestructuras y aparentemente relacionados con distintos actores. Tras la publicación de los parches, aparecieron más pruebas de concepto en cuestión de horas. Amazon sostiene que PHP2Shell está ya siendo explotado «ampliamente» en Internet. La compañía recomienda que las organizaciones investiguen sus registros desde al menos el 17 de octubre, en lugar de utilizar la fecha de divulgación como inicio de la ventana de posible compromiso.
Este punto introduce una diferencia importante entre reparar y responder al incidente. Actualizar elimina la vulnerabilidad, pero no permite descartar que un atacante hubiese accedido previamente al servidor. Los equipos de seguridad deben revisar registros web, ejecuciones de procesos, modificaciones inesperadas de archivos y otros indicadores de actividad anómala.
La NSA estadounidense ha recomendado inventariar los servicios que dependen de PHP, aplicar los parches de los distintos proveedores y retirar temporalmente de Internet los sistemas que no puedan actualizarse. La agencia advierte de que la ejecución remota podría facilitar el acceso a archivos y bases de datos, el robo de información, la interrupción de servicios o movimientos posteriores dentro de una red.
La IA acelera el descubrimiento y también la explotación
La forma en que fueron descubiertos los fallos añade otra dimensión al incidente. Investigadores de Calif identificaron una vía crítica utilizando GPT-5.6 Sol dentro del programa Patch the Planet, mientras Wiz encontró de forma independiente las dos vulnerabilidades utilizando también modelos de inteligencia artificial.
OpenAI participó durante los meses siguientes junto a los mantenedores de PHP, investigadores y proveedores de infraestructura en la validación de los fallos, el desarrollo de las correcciones y la preparación de protecciones. Google ha explicado igualmente que modelos de Gemini participaron en investigación, desarrollo de exploits de prueba, mecanismos de detección y validación de parches.
Los primeros indicios del problema de gestión de memoria, sin embargo, eran anteriores. La PHP Foundation señala que durante una auditoría externa realizada en 2024 ya aparecieron señales de la causa que posteriormente desembocaría en CVE-2026-109618. Entonces se planteó la posibilidad teórica de explotación, pero no se encontró una vía concreta para conseguir ejecución remota de código. La propia organización reconoce que el retraso posterior en resolver el problema respondió a limitaciones de recursos y a dificultades para elegir una corrección que no introdujera incompatibilidades o nuevos riesgos.
La divulgación tampoco siguió el calendario previsto. Los identificadores de las vulnerabilidades empezaron a circular el 20 de octubre, lo que llevó a adelantar un día la publicación. Horas después se difundieron accidentalmente imágenes de una prueba de concepto y Chainguard distribuyó versiones compiladas con la corrección antes de que terminase el embargo. PHP consideró que esta última decisión facilitaba comparar los binarios y estudiar el parche mientras buena parte de los usuarios todavía no podía actualizar. Chainguard defendió ante The Register que decidió publicar las correcciones porque ya había indicios de ataques reales.
El incidente muestra así cómo se está reduciendo el intervalo entre conocimiento de una vulnerabilidad, análisis del parche y aparición de código de explotación. AWS considera que las herramientas de IA abaratan la ingeniería inversa hasta el punto de permitir que más actores conviertan una corrección o un aviso técnico en un exploit en horas o minutos.
Para las empresas, esa reducción cambia los tiempos de respuesta asumibles. Los ciclos de parcheado de siete o treinta días resultan insuficientes ante vulnerabilidades críticas expuestas directamente a Internet. PHP2Shell obliga a localizar dependencias que pueden pasar desapercibidas, actualizar los sistemas soportados, buscar posibles accesos anteriores al parche y decidir si aquellos servicios que no puedan corregirse deben permanecer temporalmente fuera de línea.
