-FROM php:8.3.35-fpm-bookworm, +FROM php:8.3.36-fpm-bookworm. Quiero ver ese diff de una línea en todos los repositorios PHP esta semana. No tiene nada de ingenioso y nadie le va a dar una estrella en GitHub. Lo que hace es convertir un parche de seguridad crítico en un pull request con el pipeline en verde y el nombre de quien lo revisó. La alternativa es un hilo de correos angustiado con el proveedor de hosting y un número de ticket que en marzo nadie sabrá encontrar.

Tu intérprete es una dependencia. Es la dependencia más importante que tienes, y casi todos lo tratamos como si fuera el tiempo que hace fuera. Fijamos 140 paquetes de Composer a hashes de commit exactos, discutimos en code review por una subida menor de una librería de logging, y luego lo ejecutamos todo sobre el binario de php que hubiera en la máquina la última vez que alguien lanzó apt. PHP2Shell es un buen motivo para dejar de hacerlo, y convence más que cualquier charla de conferencia sobre builds reproducibles.

Un poco de contexto rápido para quien se pasó finales de octubre metido de lleno en un sprint. El 21 de octubre de 2026, el proyecto PHP publicó parches para CVE-2026-109618 y CVE-2026-109619. Los dos son fallos de seguridad de memoria en lo más profundo del motor. A uno se llega por una ruta de memoria agotada (out-of-memory) y el otro es un use-after-free, y juntos pueden darle a un desconocido ejecución de código en tu servidor sin iniciar sesión. Las versiones parcheadas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. No hay nada oficial para 8.1 ni versiones anteriores, y 8.2 llega al final de su vida el 31 de diciembre de 2026, así que si estás en 8.2 te toca parchear ahora y planificar una migración antes de las fiestas. El Centro Canadiense de Ciberseguridad también publicó su propio aviso, por si tu gente de cumplimiento necesita un segundo membrete.

Esto es lo que hace incómodo el fallo: no salta ninguna de tus alarmas habituales. WordPress publicó un aviso diciendo que esta vez no hace falta una versión nueva del núcleo, lo cual es cierto y además significa que el banner amarillo de actualización de wp-admin se queda callado. Sube Laravel a la última versión menor y no cambia nada. composer audit sale limpio en un servidor completamente expuesto, porque Composer nunca ha sabido nada del binario que lo ejecuta. Tu middleware, tus reglas de validación y tus hooks de WordPress no pintan nada cuando el motor que tienen debajo está comprometido. Así que si el runtime no queda registrado en algún sitio que de verdad mires, es invisible justo cuando más lo necesitas.

La objeción más fuerte merece que la escuchemos bien, y tiene dos partes. La primera: una parte enorme de PHP corre en hosting gestionado o compartido, y mucha gente lo eligió precisamente para no tener que hacerse cargo de ningún binario. Decirle a una agencia de cinco personas con 60 webs de WordPress de clientes que meta el intérprete en control de versiones es no entender por qué le paga a un hosting. La segunda: las distribuciones hacen backports de los parches sin tocar la cadena de versión original, así que un paquete de Debian o RHEL puede estar a salvo y aun así mostrar un número que parece vulnerable. Fijarte en los números oficiales puede darte falsas alarmas o, peor todavía, una falsa tranquilidad.

Me tomo las dos en serio, y aun así no creo que ninguna te libre. Puedes delegar el parcheo. Lo que no puedes delegar es saberlo. Incluso en un hosting donde nunca vas a tener una shell, tu aplicación puede informar del runtime que usa: un endpoint de salud, una comprobación de disponibilidad que lea PHP_VERSION y falle por debajo de un umbral, una línea en el log de despliegue. Si los backports enturbian la cadena de versión, registra el nombre y la release del paquete, pero regístralo en algún sitio donde puedas hacer un diff. El objetivo no es un número concreto. El objetivo es que la respuesta a "¿qué está corriendo?" sea un dato que puedes consultar y no una suposición. Los procesos de larga duración son donde suponer se vuelve peligroso. Si un master de FPM, un worker de Octane o un supervisor de Horizon lleva levantado desde el 19 de octubre, sigue ejecutando el código viejo en memoria, diga lo que diga el gestor de paquetes.

A nuestros vecinos que escriben Go el runtime se les compila dentro de cada binario, quieran o no, y lo pagan reconstruyendo todos sus servicios cada vez que cambia la toolchain. Nosotros elegimos un intérprete compartido, que es más barato, más amable y buena parte de la razón por la que PHP mueve media web desde un plan de hosting de diez euros. Es una ventaja real. Solo que viene con un poco de contabilidad, y PHP2Shell es la semana en que tocaba ponerla al día.

Así que te lo pregunto, y me encantaría leer las respuestas en los comentarios: ¿dónde vive ahora mismo, de verdad, tu versión de PHP en producción? ¿En un Dockerfile, en una variable de Ansible, en un desplegable del panel del hosting o en ningún sitio? Y si alguien te lo preguntara esta tarde, ¿podrías demostrar en diez minutos qué nivel de parche atendió tu última petición en producción?