PHP2Shell: la IA vuelve explotable un fallo viejo de PHP

PHP2Shell: dos fallos, un 9,2 sobre 10 y cero autenticación

El 21 de octubre, el proyecto PHP publicó parches de emergencia para dos vulnerabilidades en el núcleo del lenguaje que permiten ejecutar código de forma remota sin autenticarse. Ambas puntúan 9,2 sobre 10 en la escala CVSS v4.0 y se agruparon bajo el nombre PHP2Shell. El detalle que las hace distintas de un susto habitual: el error no es nuevo. Lo nuevo es que la IA de frontera volvió explotable algo que llevaba años —o décadas— ahí.

Para un founder, la consecuencia práctica es incómoda. Si tu producto, tu web o el panel de tu proveedor corren sobre PHP, esta no es una noticia de infraestructura ajena: es una revisión que tienes que hacer esta semana.

¿Qué es PHP2Shell y por qué el fallo no es nuevo?

Las dos vulnerabilidades están identificadas como CVE-2026-109618 y CVE-2026-109619. La primera es una ejecución remota de código por corrupción de memoria cuando se agota la memoria (OOM); la segunda, por un estado global obsoleto que una petición reutiliza de la anterior en el mismo trabajador. Según el aviso del proyecto PHP, las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35.

Wiz sostiene que todas las versiones de PHP publicadas en la última década están afectadas por al menos una de las dos, y que la ruta vulnerable más antigua se remonta a PHP 5.4. La Fundación PHP reconoce que el problema se reportó en 2020 y que una auditoría de OSTIF y Quarkslab en 2024 lo redescubrió sin llegar a demostrar explotación. La propia Fundación lo admite sin matices: "No vamos a pretender lo contrario: el retraso fue un fallo estructural".

Lo que cambió no fue el código, sino la capacidad de encadenar los pasos para aprovecharlo. La descripción de Wiz es precisa: los fallos llevaban décadas presentes, pero demostrar su explotabilidad exigía "una cadena de pasos excepcionalmente compleja, en el límite de lo que los investigadores humanos podían lograr en la práctica". Los modelos de IA de frontera redujeron esa barrera y convirtieron un problema latente en un exploit funcional.

¿A cuántos servidores afecta realmente?

PHP está presente en cerca del 70% de las páginas web con lenguaje identificable, según RTVE, y es la base de WordPress, que impulsa alrededor del 40% de los sitios de internet, además de Mailchimp, Drupal, Magento, Laravel y partes de Slack y Zoom, según Computerworld. La empresa de telemetría Censys identificó aproximadamente 2,58 millones de hosts expuestos a internet y 54,9 millones de propiedades web corriendo PHP, según Krebs on Security.

El riesgo alcanza a todas las instalaciones que atienden peticiones web: PHP-FPM, Apache con modphp, php-cgi, FrankenPHP y LiteSpeed. Es mayor en modphp, donde una petición sin autenticación dispara el ataque antes de que se ejecute una sola línea del código de la aplicación (Computerworld).

Las pruebas no son teóricas. Wiz combinó ambas vulnerabilidades en un script llamado php2shell y demostró ejecución remota de código sin autenticación contra imágenes de contenedor actualizadas de WordPress, Drupal y Joomla. Calif confirmó RCE preautenticación en WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4, MediaWiki 1.46.2, Roundcube 1.7.4, Magento 2.4.9, phpMyAdmin 5.2.3, Nextcloud 35.0.1, Laravel 13.11, Symfony 8.1 y WHMCS, según Unite.AI.

La reacción institucional fue inusualmente agresiva: Finlandia, Países Bajos y Francia desconectaron webs gubernamentales; Alemania retiró páginas a través de ITZBund; Bélgica y Chequia hicieron lo propio. La NSA y el FBI instaron a actualizar de inmediato, y en España INCIBE emitió una alerta de importancia crítica advirtiendo de ataques registrados antes de que se publicaran los parches. Cloudflare detectó explotación en tráfico real y desplegó reglas de firewall a las 3:02 UTC del día de la divulgación (Krebs on Security).

Conviene no confundir tres cosas distintas, como recuerda el análisis original: cuántos sitios usan PHP, cuántos corren versiones vulnerables en configuraciones atacables y cuántos han sufrido una intrusión exitosa. El 70% mide la envergadura del problema, no el número de víctimas.

¿Por qué la IA cambió el juego en ciberseguridad?

OpenAI lideró una coalición de dos meses entre mantenedores, investigadores y proveedores de seguridad. Calif identificó un fallo crítico usando GPT-5.6 Sol en el marco de la iniciativa Patch the Planet, y Wiz descubrió ambos de forma independiente con Wiz Atlas, Gemini 4 Argon y GPT-5.6 Sol (Unite.AI).

La cronología muestra descubrimientos solapados: Calif inició su auditoría el 30 de julio y reportó ejecución remota de código el 11 de agosto; Wiz encontró el primer fallo el 19 de agosto y lo reportó el 24; OpenAI sumó vectores adicionales el 18 de septiembre; y el 21 de septiembre PHP arrancó el arreglo coordinado. De fondo, el original apunta a algo más amplio: los laboratorios están usando sus modelos más avanzados para hallar vulnerabilidades, construir pruebas de explotación y validar las correcciones, una dinámica que ganó peso desde el lanzamiento de Mythos Preview por parte de Anthropic a principios de abril.

OpenAI afirma que, hasta donde sabe, la IA de frontera encontró estas vulnerabilidades antes que los atacantes, lo que abre lo que llama una "ventana de oportunidad para los defensores". La compañía comprometió 1.000 millones de dólares en acceso subsidiado a Daybreak, su programa para defensores de infraestructura crítica, y publicó un verificador de versiones de PHP como habilidad de Codex en el repositorio abierto openai/php2shell-checker.

La ventana, sin embargo, se cerró rápido. El 20 de octubre, alrededor de las 15:00 UTC, los dos CVE empezaron a circular en foros con una puntuación errónea de 10,0; hacia las 20:00 UTC Calif publicó por error un video con su prueba de concepto; y a las 07:41 UTC del 21 de octubre, Chainguard publicó imágenes con la corrección más de seis horas antes de la divulgación coordinada. El proyecto adelantó la publicación del 22 al 21 de octubre.

Matt Saunders, responsable de DevOps en Adaptavist, resume el riesgo en Computerworld: "Tan pronto como se anuncie la vulnerabilidad, legiones de bots de IA buscarán sistemas que explotar". OpenAI reconoce el doble filo: las mismas capacidades que ayudan a encontrar fallos sirven para desarrollar herramientas ofensivas.

¿Qué significa esto para tu startup?

1. Haz un inventario real, no solo de tu web corporativa. El Centro Nacional de Ciberseguridad de Países Bajos advierte que PHP también está integrado en dispositivos de red, interfaces de gestión y productos de terceros donde quizá no puedas actualizarlo tú. Pregunta a tus proveedores y a tu hosting por su estado de parcheo, por escrito.

2. Verifica la versión y actualiza hoy. Si estás en una rama con soporte, necesitas 8.5.12, 8.4.27, 8.3.36 o 8.2.35. Si sigues en 7.4, 8.0 u 8.1, el proyecto publicó parches retroportados, aunque la recomendación es migrar. Si no puedes actualizar un servidor expuesto a internet, INCIBE aconseja aislarlo de las redes públicas hasta que puedas.

3. Asume que pudiste estar comprometido antes. "Un parche corrige la vulnerabilidad; no elimina necesariamente el acceso que un atacante pueda haber establecido ya", advierte Madelein van der Hout, analista de Forrester, en Computerworld. Revisa registros, busca procesos de PHP que abran terminales o descarguen archivos de forma inesperada (recomendación del FBI), aísla el equipo y conserva los logs para la investigación.

4. Prioriza por exposición, no por importancia del negocio. Lo conectado a internet primero. Forrester lo dice claro: "No basta con comprobar únicamente el sitio web corporativo".

5. Si vendes sitios o software, esto es un problema de comunicación. Agencias, tiendas WooCommerce en hosting compartido y SaaS construidos sobre Laravel o Symfony deberían avisar a sus clientes, documentar el estado de parcheo y dar fechas concretas.

6. Anota una fecha en el calendario: PHP 8.2 llega a fin de vida el 31 de diciembre de 2026. Quien siga en 8.1 o anterior quedará fuera de soporte en plena resaca de este incidente.

La lección de fondo: tu dependencia más crítica quizá no está financiada

La Fundación PHP reconoce que el retraso fue estructural y ha pedido patrocinio a empresas, proveedores de hosting, plataformas cloud, distribuciones y gobiernos. Creó un Ecosystem Security Team en mayo de 2026, contrató a dos personas —Alexandre Daubois en julio y Daniel Scherzer en septiembre— y desde el 1 de julio publicó 15 CVE mientras procesaba más de 100 reportes que resultaron inválidos, duplicados o no reproducibles (Unite.AI).

Krebs on Security y Wiz comparan la escala del episodio con Log4Shell en 2021: un fallo en una dependencia ubicua que nadie mira porque "siempre funcionó". La diferencia es que ahora la IA reduce drásticamente el tiempo y el conocimiento necesarios para convertir una vulnerabilidad conocida en un ataque exitoso, como señala el artículo original.

Conclusión

PHP2Shell no es una historia sobre un bug: es una historia sobre deuda técnica acumulada durante una década y sobre quién paga la cuenta de mantener la infraestructura abierta. La IA aceleró el descubrimiento, pero también el ataque. Para una startup, la lección accionable es simple: saber exactamente qué corre en tu stack, quién lo mantiene y cuánto tardas en parchear. La próxima vez, la ventana entre el parche y el exploit será todavía más corta.

Fuentes

• Xataka — La IA no ha encontrado un fallo nuevo en PHP, sino algo peor (fuente original)
• RTVE — Alerta mundial por dos fallos críticos en PHP
• Computerworld España — Dos fallos críticos de PHP ponen en alerta a Internet
• Krebs on Security — Widespread PHP Flaw May Cause Many Site Outages Today
• Unite.AI — PHP Patches Two Critical RCE Flaws Found with Frontier AI Models