El propio aviso de PHP describe CVE-2026-109619 como ejecución remota de código a través de estado obsoleto en los workers, y no paro de releer esa frase porque retrata nuestros hábitos de despliegue tanto como el bug. El 21 de octubre el proyecto PHP publicó 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que corrigen ese fallo y también CVE-2026-109618, una vía de corrupción por falta de memoria. Los dos tienen una puntuación CVSS v4.0 de 9.2 y los dos se pueden explotar sin autenticación. Mi postura es sencilla: la lista de versiones es lo fácil de esta semana. Lo que la mayoría de los equipos no sabe hacer, y debería darle suficiente vergüenza como para aprenderlo, es demostrar qué build de PHP está sirviendo cada petición en cada host en este preciso momento.

Fíjate en cómo llega de verdad la corrección a producción. Puede que tu distribución la haya portado a un paquete que sigue diciendo 8.5.4 o 8.3.algo, así que la cadena de versión te dice bien poco. Puede que tu imagen de contenedor esté parcheada en el registro mientras tres réplicas de agosto siguen sirviendo tráfico tan tranquilas. Puede que el proceso maestro de PHP-FPM se haya actualizado en disco a las 03:12 mientras sus hijos conservan el código viejo en memoria hasta que alguien reinicie el servicio. Y el binario CLI que compruebas con php -v por SSH puede ser un build distinto del que usan Apache o FPM para el sitio. Wordfence lo dice claramente y manda a quienes gestionan WordPress a Tools > Site Health > Info > Server en lugar de a la shell, y la verdad es que cualquier equipo que trabaje con frameworks agradecería una página equivalente.

Los resultados de laboratorio del equipo Wordfence Threat Intelligence merecen una lectura atenta, porque cortan en ambas direcciones. En un laboratorio con Apache y PHP 8.5.11 configurado especialmente, su prueba de concepto para CVE-2026-109619 viajó por HTTP normal y escribió un archivo de texto temporal, lo cual es ejecución de código se mire como se mire. Contra un build 8.5.11 optimizado normal, la misma petición solo hizo caer PHP. Con CVE-2026-109618 vieron que 8.5.11 se caía donde 8.5.12 respondía con normalidad, y en una pila con WordPress 7.1.3 y un paquete de Ubuntu 8.5.4 afectado consiguieron fallos y reinicios en algunas configuraciones, aunque ellos no llegaron a ejecutar código.

Este es el mejor argumento para tomárselo con calma, y quiero darle todo su peso. Si el exploit público necesita un build ajustado en laboratorio para hacer algo más que tumbar un worker, entonces en un servidor de producción típico el resultado realista hoy es una denegación de servicio, y buena parte del código de prueba de concepto que circula es, según la propia Wordfence, incompleto o directamente erróneo. Parchear con prisas un viernes tiene sus propios riesgos, y quien haya roto un flujo de pago por un reinicio precipitado sabe que ese coste es real.

Aun así, no me convence. CrowdStrike asegura que su exploit no publicado funcionó de forma fiable tanto en Intel/AMD como en Arm, incluso contra workers recién reiniciados, y el propio PHP confirmó ejecución de código para ambos bugs, con una vía de 109618 que se dispara antes incluso de que arranque WordPress. Ese último detalle importa a todo el mundo, uses framework o no: ningún firewall de aplicación, ningún middleware, ningún validador ingenioso en tu kernel de Laravel o Symfony llega a ver una petición que explota antes de que se ejecute tu código. Los exploits que esta semana solo tumban cosas son un pronóstico razonable de lo que serán la semana que viene, y un pool de FPM cayéndose bajo un ataque ya es una caída del servicio que vas a tener que explicarle a alguien.

Así que lo que me gustaría sacar de este incidente es un hábito. Trata la pregunta "qué PHP está vivo aquí, desde cuándo y con qué revisión de paquete" como un dato observable que puedes consultar, igual que consultas qué commit está desplegado. Exponlo en un endpoint de salud protegido con autenticación, regístralo en el log cuando arranca cada worker, mete el digest de la imagen en las etiquetas de tus métricas. Los de Go pueden presumir de que un binario estático lo hace trivial, y vale, en eso concreto tienen razón, pero nosotros tenemos opcache_get_status, php_uname, PHP_VERSION y el gestor de paquetes, y juntarlo todo lleva una tarde. Hazlo antes del próximo aviso, luego repasa los sitios de staging y las IP de origen que Wordfence menciona con acierto, y guarda tus logs web, de PHP y del firewall desde 48 horas antes de la publicación en adelante por si llegaste tarde.

Una última nota incómoda para quien siga en 8.1 o anterior: el proyecto PHP ya no publica versiones para esas ramas, así que tu seguridad depende por completo de que un proveedor te diga, por escrito, que ha incorporado las dos correcciones. Si no consigues que te escriban esa frase, ya tienes tu respuesta, y la actualización que llevas tiempo aplazando acaba de ganarse una fecha límite.

Tengo curiosidad por saber cómo lo resuelven tus equipos en la práctica. Cuando sale una versión de seguridad, ¿cómo confirmas de verdad que cada proceso PHP en ejecución, entre pools de FPM, workers de colas, contenedores de cron y esa máquina virtual heredada, está con el código corregido, y cuánto tardaste esta vez?