La IA extrajo un bug de 20 años del núcleo de PHP. Ahora ejecuta código en su servidor. Parchee hoy.

El 21 de octubre el proyecto PHP publicó cuatro versiones a la vez, 8.5.12, 8.4.27, 8.3.36 y 8.2.35, para corregir dos vulnerabilidades críticas con puntuación CVSS 9,2 cada una: CVE-2026-109618 y CVE-2026-109619. Juntas reciben el nombre de php2shell. Cualquiera de ellas permite a un atacante no autenticado ejecutar código en un servidor que no hace más que servir PHP. No interviene ningún fallo de la aplicación. Una simple página «Hello World» en una versión vulnerable es suficiente.

Ambas vulnerabilidades residen en las partes de PHP que casi todas las peticiones tocan: la gestión de memoria y el manejo de errores. CVE-2026-109618 corrompe la memoria en la forma en que PHP hace limpieza cuando se queda sin memoria a mitad de una petición. CVE-2026-109619 es un use-after-free, donde el estado interno de una petición persiste en la siguiente petición gestionada por el mismo worker. Wiz Research las descubrió con ayuda de agentes de IA, las notificó de forma privada en agosto y el parche llegó el 21 de octubre en una publicación coordinada con distribuciones y proveedores. Wiz afirma que todas las versiones de PHP desde la 5.4 están afectadas, lo que abarca aproximadamente la última década del lenguaje. PHP ejecuta una gran parte de la web, por lo que el número de servidores expuestos es enorme.

Quién está realmente expuesto

El equipo de PHP califica Apache con mod_php como el riesgo más alto. Allí, una sola petición no autenticada puede desencadenar el exploit antes de que se ejecute ningún código propio, por lo que ninguna de sus defensas —middleware de autenticación, validación de entrada, comprobaciones internas— llega a tener turno. Se demostró ejecución remota de código completa en mod_php con la configuración predeterminada contra contenedores recién instalados de WordPress, Drupal y Joomla.

PHP-FPM tampoco está a salvo. El RCE a través del fallo de estado obsoleto fue validado en FPM, aunque ese camino necesita una operación adecuada en la aplicación en ejecución para alcanzarlo. php-cgi, FrankenPHP y LiteSpeed están todos en el alcance. Si sirve PHP por HTTP, trátelo como vulnerable hasta que lo haya parcheado y reiniciado.

Una advertencia para los equipos móviles, porque la exposición es fácil de pasar por alto: en nuestros proyectos nativos de iOS y Android la propia aplicación está limpia, pero se comunica con una API, y esa API es muy a menudo PHP. Un backend sin parchear pone en riesgo a sus usuarios aunque no haya nada incorrecto en el dispositivo. Compruebe el servidor que hay detrás de la aplicación, no solo la aplicación.

Qué haríamos primero

En nuestra experiencia con PHP y con trabajos en Docker, el error que vemos bajo presión es parchear lo incorrecto. Hay dos pasos que importan más que el resto.

1. Encuentre todos los PHP que ejecuta, no solo el más obvio. Se esconde en stacks de cPanel y Plesk, appliances de proveedores, sitios de clientes antiguos que nadie ha tocado en dos años, imágenes de CI y contenedores base. La guía de CISA indica que primero hay que hacer un inventario, porque PHP suele estar enterrado dentro de otro software y no se puede parchear lo que no se ha encontrado.
2. Parchee, luego reinicie, luego verifique la versión que reporta el proceso en ejecución. Un paquete nuevo en disco no hace nada hasta que se reemplazan los workers en ejecución. Hemos visto equipos que «parchean» y permanecen vulnerables durante días porque PHP-FPM nunca llegó a reiniciarse.

Los contenedores empeoran esta trampa. Ejecutar una actualización dentro de un contenedor en ejecución no es una solución, porque el próximo despliegue desde la imagen antigua vuelve a traer la versión vulnerable. Reconstruya sobre una imagen base parcheada, publíquela y rote los workers. Luego acceda al servidor y confirme que la versión que espera es la que está respondiendo.

Si genuinamente no puede parchear hoy

El equipo de PHP es claro: solo actualizar es una solución completa, y la configuración provisional solo reduce rutas de ataque específicas. Las que vale la pena aplicar son memory_limit=-1 forzado donde la aplicación no pueda sobreescribirlo, usando php_admin_value en su pool de FPM o configuración de Apache, luego session.upload_progress.enabled=0, y un post_max_size conservador. Si usa Cloudflare, la regla del WAF gestionado para estos CVEs ya está activa, y ganar tiempo con una regla de borde mientras se parchean los workers es exactamente el tipo de cosa que configuramos cuando preparamos Cloudflare para clientes durante un incidente. Un detalle importante: esa regla se basa en el nombre de campo predeterminado de upload-progress, así que si cambió session.upload_progress.name, no lo cubrirá.

La parte que debería preocuparle más que este bug

Esto es lo que me llama la atención de php2shell. Estos bugs llevan en el código base unos veinte años. Nadie los había armado porque convertir una cadena de corrupción de memoria en un exploit fiable para cada versión de PHP, conjunto de extensiones y disposición del heap era un trabajo lento y especializado, del tipo que lleva meses. Wiz utilizó modelos de IA de frontera para hacer esa adaptación, y tardó un par de semanas en lugar de meses.

Durante nuestros trabajos de pentesting para estudios de videojuegos, la parte difícil raramente era detectar una ruta de código sospechosa. Era demostrar un exploit real y reproducible antes de que alguien pagara para corregirlo. Esa economía ha cambiado. Los atacantes obtienen la misma aceleración, lo que significa que la brecha entre la publicación de un parche y el escaneo masivo sigue reduciéndose. Cloudflare reportó intentos de sondeo cerca del momento de la publicación, y ya circula una prueba de concepto.

Así que la conclusión honesta es incómoda: su cadencia de parches es ahora su postura de seguridad. Si no puede encontrar y actualizar un runtime crítico en todo su entorno en un día, esa es la brecha real, y php2shell no será la última prueba.

Si mantener PHP parcheado, reiniciado y verificado en staging, producción y un montón de sitios de clientes antiguos le suena familiar, hablemos.