PHP2Shell: una IA ayudó a descubrir fallos críticos en PHP que llevaban años ocultos

Dos vulnerabilidades críticas en el núcleo de PHP permiten, bajo determinadas condiciones, ejecutar código de forma remota sin autenticación.

Dos vulnerabilidades críticas en el núcleo de PHP permiten, bajo determinadas condiciones, ejecutar código de forma remota sin autenticación. El equipo de PHP publicó correcciones el 21 de octubre de 2026. La investigación de Wiz Research, realizada con herramientas de inteligencia artificial y en colaboración con Calif y OpenAI, ayudó a identificar y demostrar el impacto de fallos que habían permanecido en el código durante más de una década.

La noticia combina dos problemas que conviene analizar por separado: el potencial de la IA para acelerar la investigación de seguridad y la dificultad de corregir software antiguo que sigue expuesto en producción.

Qué pasó

Las vulnerabilidades se identifican como CVE-2026-109618 y CVE-2026-109619. Ambas afectan al núcleo de PHP y tienen una puntuación de 9,2 sobre 10 en CVSS v4.0, según el aviso oficial del proyecto.

En términos generales, los fallos están relacionados con el manejo de errores fatales y el estado interno de PHP entre peticiones:

CVE-2026-109618: una condición de falta de memoria puede interrumpir el procesamiento cuando ciertos datos internos están parcialmente inicializados. Durante la limpieza posterior, PHP puede manejar ese estado de forma insegura.
CVE-2026-109619: parte del estado interno asociado a una petición puede sobrevivir después de liberar la memoria que lo respaldaba. Una petición posterior atendida por el mismo proceso puede reutilizar ese estado obsoleto.

La explotación puede permitir ejecución remota de código sin autenticación. PHP considera que el riesgo es especialmente alto con Apache y mod_php, donde se demostró una ruta de explotación antes de que se ejecute el código de la aplicación. El aviso oficial también incluye instalaciones que atienden peticiones web mediante PHP-FPM, php-cgi, FrankenPHP y LiteSpeed; el riesgo concreto depende de la ruta de ejecución y la configuración.

Las versiones oficiales corregidas son:

Rama	Versión corregida
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

PHP indica que no existe una mitigación completa equivalente al parche y recomienda actualizar. Si PHP procede de una distribución Linux, un panel de hosting o un proveedor externo, hay que comprobar el estado de sus paquetes: el número de versión por sí solo no siempre refleja si una distribución ha aplicado un backport de seguridad.

¿Ya se estaba explotando?

Sí. Amazon Threat Intelligence publicó el 21 de octubre que detectó en su red de sistemas señuelo MadPot un intento de explotación fechado el 17 de octubre de 2026, cuatro días antes de la divulgación pública de los CVE. AWS indicó que el intento procedía de una dirección IP asociada a una red comercial de anonimización, pero que no estaba claro cómo el actor había obtenido información sobre la vulnerabilidad antes del fin del embargo.

AWS también informó que, el 21 de octubre, observó varias pruebas de concepto y nuevos intentos desde distintas infraestructuras de anonimización. La empresa señaló que las cargas útiles y la infraestructura variaban, lo que apuntaba a varios actores. Sin embargo, aclaró que el análisis seguía en curso y que no podía confirmar que esos intentos hubieran tenido éxito en sistemas reales. El informe sí concluye que, después de publicarse el parche y los detalles técnicos, aparecieron pruebas de concepto en pocas horas y se utilizaron casi inmediatamente contra sus sensores. AWS caracteriza actualmente la actividad como explotación extendida en Internet; esa afirmación debe atribuirse a su telemetría, no interpretarse como prueba de que todos los intentos hayan comprometido víctimas.

Fuente primaria: Amazon Threat Intelligence / AWS Security Blog.

Cómo entró la IA en la investigación

Wiz Research publicó su análisis el 21 de octubre. Según la cronología de su informe, el equipo identificó la primera vulnerabilidad el 19 de agosto, confirmó ejecución remota de código contra Drupal y WordPress en los días siguientes y notificó al equipo de seguridad de PHP el 24 de agosto. Las correcciones se publicaron el 21 de octubre.

Wiz Research afirma explícitamente que las vulnerabilidades afectan a versiones de PHP que se remontan a PHP 5.4. El calendario oficial de PHP confirma que PHP 5.4.0 se publicó el 1 de marzo de 2012: al publicarse este artículo, eso sitúa la versión más antigua mencionada en más de catorce años atrás. La precisión importante es atribuir ese alcance histórico a la investigación de Wiz. El aviso oficial de PHP se centra en las ramas y versiones corregidas; no afirma que el equipo del proyecto haya probado individualmente todas las versiones históricas. Wiz Research · Anuncio oficial de PHP 5.4.0

Wiz explica que utilizó varias herramientas, entre ellas Wiz Atlas, Gemini 4 Argon y GPT-5.6 Sol. Según la firma, la IA ayudó a comprender el comportamiento interno del motor y a convertir errores difíciles de encadenar en una explotación funcional. Calif, por su parte, identificó una falla crítica con GPT-5.6 Sol dentro de la iniciativa Patch the Planet de OpenAI; Wiz informó que descubrió y notificó vulnerabilidades relacionadas de forma independiente. Los mantenedores de PHP lideraron la corrección. Por tanto, no se trata de que una IA publicara por sí sola un parche, sino de investigación asistida por modelos, reproducción de los fallos, revisión humana y trabajo coordinado con quienes mantienen el lenguaje. Wiz Research · OpenAI

¿Por qué no se había detectado antes?

La respuesta requiere un matiz: el problema no pasó completamente inadvertido. Según la PHP Foundation, una auditoría externa del código de PHP realizada en 2024 encontró indicios del problema relacionado con errores de falta de memoria (out of memory, u OOM). Un desarrollador del núcleo llegó a teorizar un posible exploit, pero entonces no se habían encontrado vectores concretos que demostraran cómo convertir ese comportamiento en ejecución remota de código. La solución también planteaba decisiones difíciles de compatibilidad y seguridad, y no se alcanzó rápidamente un consenso sobre el arreglo. PHP Foundation

Hay varias razones por las que un fallo así puede permanecer años en un proyecto maduro:

No es un error visible en el uso normal. Aparece en circunstancias excepcionales, cuando una petición provoca un error fatal —por ejemplo, al quedarse sin memoria— durante una etapa delicada del procesamiento.
El problema cruza el límite entre peticiones. PHP puede liberar memoria al terminar una petición, pero dejar una referencia interna que una petición posterior, atendida por el mismo proceso, vuelve a utilizar. Es difícil detectar ese tipo de secuencia si se prueba cada petición como si fuera independiente.
Encontrar un fallo no es lo mismo que demostrar una explotación. Los investigadores tuvieron que encadenar comportamientos de memoria, provocar las condiciones necesarias de manera controlada y adaptar la técnica a diferencias de versiones, configuración y distribución de memoria. Una prueba que funciona en un entorno puede fallar en otro.
Los errores de memoria son difíciles de revisar y reproducir. Las pruebas habituales pueden no activar la condición exacta. Las herramientas de análisis ayudan, pero no garantizan por sí solas que se encuentre una cadena explotable en todas las rutas del programa.
También hubo un factor organizativo. La PHP Foundation reconoce que el arreglo se retrasó por la dificultad de elegir entre alternativas con distintos costes, la falta de una ruta de explotación demostrada y los recursos limitados del equipo con conocimiento profundo del motor. No sería exacto atribuir toda la demora a una incapacidad técnica para ver el error.

La contribución de la IA fue reducir el trabajo necesario para explorar el código, formular hipótesis, probar secuencias y depurar una cadena compleja hasta demostrar su impacto. En otras palabras, no necesariamente hizo visible de repente una línea de código sospechosa: ayudó a convertir un problema difícil de explotar en una vulnerabilidad cuyo riesgo podía demostrarse y priorizarse. Esa distinción explica por qué el hallazgo cambió la urgencia con la que se abordó el fallo.

El caso tampoco aparece aislado. En julio de 2026, Searchlight Cyber publicó wp2shell, una cadena de vulnerabilidades en WordPress Core descubierta con ayuda de un modelo de OpenAI. El caso muestra cómo la IA puede reducir el tiempo necesario para investigar fallos complejos. También deja una advertencia: una vez divulgada una vulnerabilidad, otros investigadores y atacantes pueden reproducirla con rapidez.

El problema real: qué ocurre con las instalaciones sin soporte

El proyecto PHP publicó versiones corregidas para las ramas 8.2 a 8.5. También preparó backports mínimos del código fuente para PHP 7.4, 8.0 y 8.1, destinados a quienes compilan por su cuenta o no pueden obtener paquetes de un proveedor. Esas ramas ya no reciben actualizaciones regulares del proyecto, por lo que las organizaciones deben comprobar qué ofrece su distribución o proveedor de soporte extendido. Para PHP 7.3 y anteriores no hay una versión corregida publicada por el proyecto PHP en el aviso consultado.

La ventana de soporte importa. PHP 8.2 llega al fin de su soporte de seguridad el 31 de diciembre de 2026. Aunque recibió esta corrección, conviene planificar la migración antes de esa fecha.

¿Cuántos servidores podrían estar expuestos?

Las cifras públicas disponibles son estimaciones de terceros y no representan un inventario completo de servidores vulnerables.

Estimación de Mallory basada en datos de Shodan, consultados el 20 de octubre: alrededor de 1,5 millones de hosts mostraban una versión de PHP. De ellos, 883.717 (aproximadamente el 59 %) ejecutaban PHP 8.1 o anterior. La publicación señala además unos 740.000 hosts que no revelaban su versión, lo que impide conocer el total exacto. PHP 5.6 y PHP 7.2 sumarían cerca de 371.000 hosts en el conjunto observado. Este conteo debe leerse como una estimación de exposición basada en la información que Shodan podía observar en esa fecha, no como un censo completo ni como una cifra de sistemas confirmados como vulnerables. Que un host muestre una versión antigua no demuestra por sí solo que sea explotable en todas las configuraciones; del mismo modo, que oculte la versión no significa que esté actualizado.

La deuda en cadena: aplicación, PHP y sistema operativo

En muchas infraestructuras, la versión de PHP no es una decisión aislada. Una aplicación antigua puede depender de PHP 5 o PHP 7, y ese runtime puede estar instalado sobre un sistema operativo que también perdió soporte.

Un ejemplo es CentOS Linux 7, cuyo ciclo de vida terminó el 30 de junio de 2024. En la familia RHEL 7, la versión de PHP incluida por defecto era PHP 5.4, por lo que ese runtime es una posibilidad real en instalaciones que conservaron los paquetes originales; no debe asumirse que todas las máquinas CentOS 7 lo utilizan, porque la versión depende de los repositorios y de la configuración. Mantener estas aplicaciones puede requerir migración, paquetes de terceros o soporte extendido. CentOS: fin de vida de CentOS Linux 7 · Red Hat: PHP predeterminado en RHEL 7.

Actualizar PHP puede romper compatibilidad con aplicaciones heredadas. Pero mantener una versión vulnerable tampoco es una solución sostenible. El trabajo real incluye inventariar dependencias, probar compatibilidad, elegir una fuente confiable de paquetes y validar la aplicación después del cambio.

Algunos proveedores de distribuciones y soporte extendido pueden publicar backports para ramas antiguas. Por ejemplo, AlmaLinux informó el 21 de octubre de 2026 que sus paquetes corregidos ya estaban desplegándose en los repositorios de producción para todos los flujos de PHP que distribuye en AlmaLinux 8, 9 y 10, incluidos algunos flujos retirados. La propia distribución advierte que las futuras correcciones para esos flujos retirados no están garantizadas. Estos paquetes corrigen el código sin necesariamente cambiar el número de versión upstream de PHP; hay que verificar la versión del paquete de la distribución y confirmar de dónde se instaló PHP. AlmaLinux: paquetes corregidos y versiones.

La cadena es clara: una aplicación atada a un runtime antiguo puede quedar atada, a su vez, a un sistema operativo sin soporte. Cada dependencia vencida encarece la siguiente actualización.

PHP está en todas partes, pero ¿qué significa el 70 %?

Wiz describe PHP como una tecnología que impulsa aproximadamente el 70 % de los sitios web. Es una estimación de uso citada por la firma, no una medida del porcentaje de sitios vulnerables ni del número de servidores que ejecutan una configuración explotable.

Wiz demostró la explotación contra imágenes de contenedor de WordPress, Drupal y Joomla disponibles en el momento de las pruebas. Esos ejemplos ayudan a ilustrar el alcance, pero la vulnerabilidad está en el motor PHP, no en un fallo específico de esos CMS. Por ello, revisar únicamente el código de la aplicación no basta: también hay que identificar qué runtime PHP ejecuta cada servicio.

Latinoamérica: una puerta rápida a Internet, desde pequeños negocios hasta gobiernos

PHP ha tenido un papel importante en la web porque reduce la barrera de entrada para publicar y mantener sitios dinámicos. Junto con herramientas como WordPress, Drupal, Joomla y plataformas de comercio electrónico, permite construir un sitio funcional sin desarrollar desde cero el sistema de publicación, la administración de contenidos, los usuarios o buena parte de las funciones habituales. El amplio ecosistema de alojamiento compartido y proveedores administrados también facilita que una persona, un emprendimiento o una pequeña empresa ponga su presencia digital en marcha sin gestionar toda la infraestructura por su cuenta.

Esta facilidad no se limita a proyectos pequeños. Entidades gubernamentales, medios de comunicación y grandes empresas también mantienen sitios web que utilizan PHP, ya sea como tecnología principal o como componente de apoyo dentro de una arquitectura más amplia. CMS populares como WordPress, Drupal y Joomla permiten publicar y administrar contenidos sin desarrollar desde cero todas esas funciones. En organizaciones grandes, PHP puede convivir con otros lenguajes y plataformas, y estar presente solo en determinados sitios o subsistemas; no debe asumirse que toda su infraestructura depende de él.

La adopción de PHP es global, no exclusivamente latinoamericana. W3Techs lo sitúa en torno al 70 % de los sitios web para los que puede identificar el lenguaje del lado del servidor; esa cifra no es una estimación específica para América Latina ni indica cuántos sitios son vulnerables. Los conteos de tecnologías web de servicios como BuiltWith también identifican numerosos sitios PHP en países de la región, pero no equivalen a servidores únicos ni permiten conocer qué versiones ejecutan. Por eso, no hay base suficiente para convertir esas cifras en un total regional de sistemas afectados.

La relevancia para PHP2Shell está precisamente en la amplitud de ese ecosistema. Una misma tecnología puede sostener desde la página de un profesional independiente hasta una tienda, un portal corporativo o un sitio institucional. Pero la rapidez para publicar no garantiza que el entorno se mantenga actualizado durante años. Un sitio puede seguir funcionando mientras su versión de PHP, sus dependencias o el sistema operativo que lo aloja quedan fuera de soporte.

En servicios de alojamiento compartido o administrado, el propietario del sitio quizá no pueda actualizar PHP directamente. En esos casos debe pedir al proveedor que confirme qué versión o paquete está desplegado, si la corrección ya fue aplicada y si se reiniciaron los procesos que atienden las peticiones. Quienes administran su propia infraestructura deben inventariar todas las instalaciones, incluidos contenedores, imágenes base y aplicaciones heredadas. No basta con consultar php -v: el PHP de la línea de comandos puede ser distinto del que utiliza el servidor web o PHP-FPM.

La conclusión no es que PHP sea inseguro por ser popular ni que todas las instalaciones estén expuestas. Es que una tecnología de adopción amplia multiplica la importancia de una respuesta coordinada: desarrolladores, propietarios de sitios, equipos de infraestructura y proveedores de hosting deben saber qué ejecutan y quién se ocupa de mantenerlo actualizado.

Qué hacer ahora

El aviso oficial de PHP recomienda actualizar; las siguientes medidas ayudan a organizar la respuesta:

Inventariar las instalaciones de PHP en servidores, contenedores, imágenes base, aplicaciones y servicios administrados.
Actualizar a una versión corregida: 8.5.12, 8.4.27, 8.3.36 o 8.2.35, o instalar el paquete corregido que publique la distribución o el proveedor.
Verificar el runtime que atiende tráfico real, no solo la versión de PHP CLI. Reiniciar los procesos o servicios correspondientes cuando lo requiera el procedimiento de actualización.
Para ramas antiguas, consultar al proveedor si existe un backport específico. Si no hay corrección disponible, priorizar la migración y reducir temporalmente la exposición de los sistemas afectados.
Tratar un WAF como defensa complementaria, no como reemplazo del parche. Microsoft publicó mitigaciones para patrones de explotación conocidos en Azure WAF, pero aclara que actualizar PHP es la única forma de corregir completamente la vulnerabilidad. La protección depende de la regla y su configuración; algunas medidas requieren habilitación explícita. Microsoft: orientación para Azure WAF.
Revisar los registros y procesos del servidor en busca de actividad anómala, especialmente si el sistema estuvo expuesto sin parche. La actualización corrige la vulnerabilidad, pero no demuestra que el servidor no haya sido comprometido antes.
Definir un plan de salida para software sin soporte. El objetivo no debería ser conseguir un parche aislado cada vez que aparece una vulnerabilidad, sino reducir la dependencia de runtimes y sistemas operativos obsoletos.

Estas medidas no tienen el mismo valor: actualizar o aplicar un paquete corregido por un proveedor confiable es la acción principal. El aislamiento, el WAF y la monitorización reducen riesgo o ayudan a detectar actividad, pero no equivalen a una corrección completa.

¿Podría ser el próximo Log4Shell?

La comparación con Log4Shell (CVE-2021-44228) es útil para entender por qué PHP2Shell merece atención inmediata. Log4Shell afectó a Apache Log4j 2, una biblioteca de registro utilizada por numerosas aplicaciones Java y productos empresariales. La vulnerabilidad podía permitir ejecución remota de código en determinadas condiciones y su respuesta fue especialmente difícil porque Log4j podía estar incluido indirectamente dentro de aplicaciones y productos. CISA y otras agencias documentaron explotación activa, escaneo generalizado y la necesidad de localizar y actualizar los sistemas afectados. (CISA: guía conjunta sobre Log4Shell)

PHP2Shell comparte algunos de esos ingredientes: afecta al propio runtime, puede permitir ejecución de código sin autenticación y su alcance potencial se extiende más allá de un CMS concreto. Un sitio no necesita utilizar WordPress, Drupal o Joomla para estar expuesto; lo determinante es la versión y la configuración de PHP que procesa las peticiones. (Wiz Research: PHP2Shell)

Pero hay diferencias importantes. Log4Shell fue explotable con relativa facilidad en muchos entornos afectados y resultó difícil localizar todas las copias de Log4j, incluidas las dependencias indirectas. PHP suele ser una parte más visible de la infraestructura web, lo que puede facilitar inventariar las instalaciones, aunque no siempre sea evidente qué runtime atiende el tráfico. Los análisis iniciales describen PHP2Shell como una cadena de explotación más compleja y dependiente de condiciones específicas. (Check Point Research: estado inicial de PHP2Shell; Filigran: comparación con Log4Shell)

Sin embargo, esa complejidad ya no debe interpretarse como una garantía de protección. La investigación de Wiz describe cómo los modelos de frontera ayudaron a convertir una cadena difícil de explotar en una demostración funcional y a adaptarla a distintas aplicaciones y entornos mediante pruebas y depuración repetidas. La misma capacidad puede ser utilizada por actores maliciosos para estudiar el fallo, automatizar parte de la experimentación y adaptar técnicas a más objetivos. Eso no significa que cualquier modelo pueda comprometer automáticamente cualquier servidor, pero sí que la experiencia especializada y el tiempo necesarios para desarrollar una explotación pueden reducirse. (Wiz Research: PHP2Shell)

Y la carrera no es hipotética: Amazon Threat Intelligence informó que observó intentos de explotación contra sus sistemas señuelo antes de la divulgación pública y que, después de publicarse el parche, aparecieron pruebas de concepto en cuestión de horas y se utilizaron contra sus sensores casi inmediatamente. AWS indicó que el análisis seguía en curso y que no estaba claro si los intentos previos habrían tenido éxito en sistemas reales. Es una señal de rapidez y actividad, no una prueba de que todos esos intentos lograran comprometer víctimas. (AWS Security Blog: actividad de explotación de PHP2Shell)

Por eso, PHP2Shell podría alcanzar un impacto comparable al de Log4Shell, pero todavía no hay base suficiente para afirmar que lo haya igualado o superado. Lo que sí cambia es la premisa operativa: los defensores no deberían contar con que la complejidad de una explotación les conceda semanas para reaccionar. En este caso, la IA ayudó a la investigación defensiva, pero las mismas capacidades también pueden acelerar el trabajo de los atacantes. La diferencia entre ambos grupos estará en quién descubre, valida, distribuye y aplica sus herramientas primero.

La lección para los responsables de sistemas no es esperar a que PHP2Shell se convierta en “otro Log4Shell”: es tratar una vulnerabilidad crítica en una tecnología tan extendida como una prioridad, inventariar cada runtime, aplicar la corrección y comprobar que los procesos que atienden las peticiones ya están ejecutando la versión parcheada. La ventana entre conocer un fallo y verlo convertido en una herramienta práctica puede ser muy corta.

Conclusión

PHP2Shell deja dos lecciones. La primera es sobre la IA: puede ayudar a descubrir y demostrar vulnerabilidades difíciles, pero también puede acelerar la reproducción de fallos una vez que se divulgan. La segunda es más antigua: el riesgo de una vulnerabilidad depende tanto de su gravedad como de la capacidad real de las organizaciones para actualizar el software que ejecutan.

Un parche solo protege los sistemas donde se instala correctamente y entra en uso. La pregunta no es únicamente si una aplicación está escrita en PHP, sino qué versión ejecuta, quién la mantiene y si existe una ruta viable para corregirla.

¿Sabes qué versión de PHP ejecutan tus sitios y quién se encarga de mantenerla actualizada?