CVSS 9.2, dos veces, y lo primero que tecleamos media comunidad el 21 de octubre fue php -v. Yo también lo hice, en una terminal de una máquina que estaba casi seguro de que importaba, y me devolvió un número tranquilizador que no me decía prácticamente nada. Ese comando te informa del binario CLI que hay en el PATH de tu shell. No dice nada del pool de FPM que está detrás de nginx, ni de la imagen de contenedor que alguien construyó hace tres semanas, ni del worker de colas que Supervisor arrancó un martes de agosto y que sigue vivo desde entonces.

Actualizar a la versión corregida es lo barato de esta semana. Lo caro es que la mayoría de los equipos con los que hablo no son capaces de sacar, ni de memoria ni de un archivo en un repo, la lista completa de procesos PHP que atienden tráfico de red en su nombre. Sin esa lista, el parche es una esperanza. Has actualizado las máquinas que recordabas, y el atacante se pone a trabajar con las que olvidaste.

Los hechos, en breve, porque explican por qué esto va por debajo de tu framework. CVE-2026-109618 está en cómo el motor gestiona las peticiones que revientan su límite de memoria, y CVE-2026-109619 es un use-after-free que un error fatal puede dejar preparado para lo siguiente que se ejecute. Los dos son bugs del runtime, así que tu middleware de Laravel y tus clases FormRequest tan bien escritas están en la habitación equivocada. El equipo de PHP dice además que no hay mitigaciones completas, así que no vas a encontrar ningún flag en el ini que activar mientras esperas a la ventana de mantenimiento. Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35, y no hay más opciones en la carta.

Lo que más me preocupa es la vida de los procesos. Un gestor de paquetes puede terminar su actualización sin errores mientras el motor viejo sigue corriendo en memoria, porque nadie le dijo al master de FPM que recargara. php artisan queue:work bajo Supervisor, Horizon, los workers de Octane: todo eso está pensado para aguantar semanas encendido, y es una gran virtud justo hasta que el código que cargaron es el código que necesitas quitar de en medio. Nuestros amigos de Go tienen aquí al menos una ventaja de la que pueden presumir: cuando redespliegan un binario estático, lo que corre es lo que compilaron. Nosotros tenemos a apt anunciando éxito a las 14:02 y un worker que lleva 41 días vivo sirviendo el runtime antiguo a las 14:03.

La objeción más sólida que he oído esta semana es justa. Casi todos trabajamos sobre una distro, una plataforma gestionada o una herramienta de aprovisionamiento precisamente para que nadie del equipo tenga que hacer de niñera de los runtimes, y esos proveedores sacaron paquetes corregidos enseguida. Es más, las distros a menudo hacen backport de los parches de seguridad a un número de versión anterior, así que una máquina con Debian o Ubuntu puede estar a salvo aunque php -v muestre algo que parece desfasado. De acuerdo, pero eso funciona en los dos sentidos. Si la cadena de versión puede engañarte hacia la tranquilidad, también puede engañarte hacia el peligro, y la única comprobación que lo zanja es la que se hace desde dentro del proceso que sirve las peticiones, después de que se haya reiniciado.

Así que lo que yo montaría esta semana es aburrido y pequeño. Dale a cada aplicación un endpoint de salud solo interno que devuelva PHP_VERSION y la hora de arranque del proceso desde dentro de FPM, no desde una shell, y haz que tu monitorización marque cualquier cosa anterior al parche. Haz que la CI rechace imágenes base por debajo de la versión corregida de tu rama. Mantén un único archivo por equipo con cada host, imagen y worker que ejecuta PHP, y trátalo como código. Te compensa dos veces antes de Año Nuevo: PHP 8.2 llega al fin de su vida útil el 31 de diciembre de 2026, y ese mismo archivo te dice desde el primer día quién tiene que migrar todavía.

Nada de esto sustituye a buscar problemas. Han pasado seis días desde la publicación, los fallos se pueden explotar sin iniciar sesión, y una actualización limpia no demuestra nada sobre lo que pasó antes. Revisa los logs de FPM en busca de picos de caídas, comprueba si hay archivos o cuentas de administrador que no creaste tú, y rota credenciales si algo te huele mal. Es higiene normal ante incidentes, y resulta mucho más fácil cuando ya sabes qué máquinas tienes que mirar.

Esto es lo que de verdad me gustaría que me contaras en los comentarios: ahora mismo, sin abrir una terminal, ¿sabrías decir qué versión de PHP sirvió la última petición de tu app en producción, y cómo lo demostrarías? ¿Lo compruebas desde dentro de la petición o confías en que el pipeline hizo lo que dijo? Y si tienes workers de larga duración, ¿los reinicias con cada parche del runtime o solo cuando alguien se acuerda?