# PHP2Shell: la IA descubre dos fallos zero-day RCE en el núcleo de PHP

> OpenAI y varios investigadores hallaron dos fallos RCE críticos en el núcleo de PHP mediante IA. Los entornos con PHP 8.2+ deben actualizar de inmediato.

- URL: https://roobrief.com/es/posts/php2shell-zero-day-rce
- Language: es
- Published: 2026-10-26T05:30:00.000Z
- Tags: dev
- Source: https://thephp.foundation/blog/2026/10/21/php-security-update/

**Modelos de IA de vanguardia han descubierto dos fallos zero-day de ejecución remota de código ocultos durante más de una década en el núcleo de PHP, lo que exige actualizar el runtime de inmediato.**

El equipo de desarrollo de PHP y The PHP Foundation publicaron el 21 de octubre actualizaciones de seguridad urgentes para corregir dos vulnerabilidades críticas de ejecución remota de código (RCE) en el runtime de PHP. Bautizadas conjuntamente como «PHP2Shell», las vulnerabilidades están registradas como CVE-2026-109618 y CVE-2026-109619. Ambas cuentan con una puntuación máxima en CVSS v4.0 de 9,2 (Crítica), lo que permite a atacantes remotos no autenticados ejecutar código arbitrario con privilegios del servidor web mediante peticiones HTTP manipuladas.

Los defectos no se identificaron mediante auditorías manuales, sino a través de equipos de investigación que utilizaron modelos de IA de vanguardia para analizar código base en lenguaje C. La IA de vanguardia (Frontier AI) hace referencia a los modelos de IA más avanzados.

## Un fallo de diez años en el núcleo de PHP sacado a la luz por la IA

La firma de seguridad Calif y la compañía de seguridad en la nube Wiz identificaron las vulnerabilidades de forma independiente y las reportaron de manera confidencial en agosto de 2026. El equipo de Calif localizó los fallos al someter el intérprete de PHP a análisis estático y verificación de memoria con el modelo de razonamiento GPT-5.6 Sol de OpenAI.

OpenAI aprovechó este hallazgo para poner en marcha la iniciativa «Patch the Planet». El objetivo del proyecto consiste en canalizar la inteligencia artificial hacia la ciberseguridad defensiva, facilitando que mantenedores y operadores de infraestructuras críticas corrijan fallos graves antes de que puedan ser aprovechados en ataques reales.

Ambos errores llevaban presentes en el núcleo de PHP desde la versión 5.4, persistiendo en todas las versiones intermedias hasta PHP 8.5. Al encontrarse en rutinas complejas de gestión de errores y limpieza global, habían pasado inadvertidos tanto para las herramientas convencionales de fuzzing como para las revisiones de código humanas durante más de diez años.

## Corrupción OOM y estado global residual: cómo funcionan los fallos

Las dos vulnerabilidades se aprovechan de deficiencias en la gestión de memoria y en los mecanismos de recuperación tras errores fatales en el runtime de PHP.

El primer fallo, **CVE-2026-109618**, tiene su origen en la gestión de la falta de memoria (Out-of-Memory, OOM). Cuando un script alcanza el límite establecido en `memory_limit`, PHP recurre a la función `longjmp()` de C para abortar la ejecución y limpiar el estado de la petición. No obstante, si esa falta de memoria ocurre mientras se procesan datos de formularios multipart o subidas de archivos, las estructuras internas de datos quedan parcialmente inicializadas. Durante la fase de limpieza, el motor de PHP interpreta por error esos punteros inválidos como memoria asignada válida, provocando una corrupción del heap que permite a un atacante tomar el control del flujo de ejecución.

El segundo fallo, **CVE-2026-109619**, se debe a la fuga de estados globales entre diferentes peticiones. Con el fin de optimizar el rendimiento, el núcleo de PHP permite que ciertos punteros globales apunten de forma temporal a zonas de memoria reservadas para una petición concreta. Si se produce un error no controlado, estos punteros pueden quedar sin limpiar, originando una condición típica de use-after-free (uso de memoria tras su liberación). Cuando el mismo proceso worker atiende la siguiente petición, interactúa con ese estado obsoleto, lo que provoca daños en la memoria y hace posible la ejecución de código.

## Impacto según el entorno de servidor y el riesgo de versiones obsoletas

Al residir estas vulnerabilidades en **el propio intérprete de PHP**, las protecciones a nivel de aplicación no ofrecen ninguna defensa. Un sitio web montado sobre WordPress o Laravel con un código impoluto y libre de inyecciones SQL resulta igualmente vulnerable en cuanto el servidor web traslada una petición maliciosa al motor de PHP.

El grado de exposición varía según la arquitectura de despliegue:
* **Apache mod_php**: Representa el escenario más crítico. Al ejecutarse PHP dentro del mismo espacio de memoria del servidor web y sin aislamiento de procesos, una petición no autenticada puede comprometer el servicio de inmediato.
* **PHP-FPM y FastCGI**: Dado que los procesos worker se reutilizan a lo largo de múltiples peticiones consecutivas, un atacante puede forzar una condición OOM para desestabilizar un worker y, en una petición posterior, inyectar el código para obtener acceso.

La distribución de los parches oficiales plantea además un reto operativo considerable:

| Rama | Estado | Versión corregida |
|---|---|---|
| PHP 8.5 | Soporte activo | **8.5.12** |
| PHP 8.4 | Soporte activo | **8.4.27** |
| PHP 8.3 | Solo seguridad | **8.3.36** |
| PHP 8.2 | Solo seguridad | **8.2.35** |
| PHP 8.1 y anteriores | Fin de ciclo (EOL) | **Sin parche oficial** |

Una parte sustancial de la web mundial sigue funcionando sobre versiones desfasadas como PHP 7.x, 8.0 y 8.1. Dado que el proyecto oficial no traslada parches a ramas obsoletas, estos sistemas quedarán expuestos de forma permanente a menos que se migren a una versión con soporte.

## Prioridades de parcheo y medidas inmediatas de mitigación

Diversos organismos de ciberseguridad, entre ellos la agencia estadounidense CISA, han instado a aplicar parches de forma inmediata en todos los servidores PHP conectados a Internet. Quienes gestionan estas infraestructuras deben priorizar tres actuaciones:

1. **Actualizar los paquetes del runtime**: Instalar sin demora las versiones corregidas (8.5.12, 8.4.27, 8.3.36 u 8.2.35) a través de los repositorios del sistema operativo o en las imágenes base de contenedores.
2. **Aislar y migrar versiones obsoletas**: Si se utiliza PHP 8.1 o una versión previa, es imprescindible planificar una migración urgente. Mientras tanto, se recomienda interponer reglas estrictas en el firewall de aplicaciones web (WAF) para bloquear cargas de archivos y peticiones multipart anómalas.
3. **Limitar el ciclo de vida de los workers**: Como solución temporal en PHP-FPM, se puede configurar `pm.max_requests` en 1 o en un valor muy reducido. Esto fuerza el reinicio del worker tras cada petición y neutraliza el riesgo de punteros globales residuales (CVE-2026-109619), a costa de una penalización en el rendimiento.

## Qué vigilar a partir de ahora

Este caso pone de manifiesto que el descubrimiento de vulnerabilidades asistido por IA ha superado la fase experimental para redefinir la defensa de infraestructuras críticas. Los modelos de razonamiento automático han demostrado su capacidad para detectar fallos de memoria en C que habían eludido décadas de revisiones humanas, coordinando campañas globales de parcheo en tiempo récord.

Sin embargo, estas mismas herramientas acabarán en manos de atacantes que las emplearán para buscar zero-days a escala masiva. La velocidad a la que las comunidades de código abierto y los equipos de operaciones puedan absorber y mitigar este ritmo de hallazgos será la gran prueba de fuego para los ecosistemas de software en los próximos años.

## Fuentes

- [Security Update: Remote Code Execution Vulnerabilities Fixed](https://thephp.foundation/blog/2026/10/21/php-security-update/) (The PHP Foundation)
- [Patch the Planet: Securing Critical Open-Source Infrastructure with Frontier AI](https://openai.com/index/patch-the-planet/) (OpenAI)
- [PHP2Shell: Technical Deep-Dive into CVE-2026-109618 and CVE-2026-109619](https://calif.io/blog/php2shell-cve-2026-109618) (Calif)