14:00 UTC del miércoles 21 de octubre de 2026. Esa hora estuvo días en mi calendario antes de que se publicara nada, y es lo más curioso de cómo gestionó PHP los CVE-2026-109618 y CVE-2026-109619: supimos la hora del arreglo antes de saber qué estaba roto. Dos fallos, cada uno con un 9.2 en CVSS v4.0, un aviso del CERT-EU con el número 2026-018 que mencionaba una posible ejecución remota de código y una nota en php.net que venía a decir que los detalles llegarían con la versión. Hubo quien lo interpretó como secretismo. Yo lo vi como un simulacro de incendio gratis que el proyecto regalaba a todos los equipos, y sospecho que la mayoría lo pasamos recargando la página del anuncio.

Tal como yo lo veo, lo difícil de un parche crítico del runtime es mecánico, y está en tu pipeline. Entender el fallo viene después. No puedes hacer nada útil con el texto del aviso hasta que existe, pero sí puedes averiguar un martes tranquilo si subir el nivel de parche de PHP en producción es cosa de diez minutos o un proyecto de arqueología de dos días. Si cambiar el runtime implica abrir un ticket con un proveedor de hosting cuyo soporte responde en 48 horas, ese 9.2 se ha convertido en un problema de agenda. Tu código no tenía nada que arreglar.

La semana pasada hablé con una freelance (me pidió que no diera su nombre) que mantiene unas treinta webs de clientes. El 20 de octubre era capaz de decirme de memoria la versión del framework de cada una. Lo que no sabía decirme era en cuáles tenía siquiera permiso para actualizar PHP. Once estaban en hosting compartido, donde la versión de PHP es un desplegable que rellena otra persona. Cuatro vivían en un VPS que montó en 2021 una antigua agencia, con una compilación hecha a mano que nadie se atrevía a tocar. Eso no es negligencia. Nuestras herramientas cuidan el composer.lock con mimo y tratan el intérprete que hay debajo como si fuera el clima: algo que simplemente pasa.

La objeción más sólida al modelo del preaviso merece que la escuchemos en serio. Anunciar una versión crítica sin detalles podría avisar a los atacantes de que se acerca algo jugoso, y también avisa a los directivos, que reenvían un titular alarmante y preguntan si la tienda online debería desconectarse. El propio texto del CERT-EU no ayudó mucho a los partidarios de la calma: cuando no se pueda corregir rápido, sugiere plantearse aislar de las redes públicas las aplicaciones expuestas a internet hasta que haya un arreglo. Leído deprisa, suena a «desenchúfalo todo», y vi al menos un canal de Slack entrar en espiral justo con esa lectura.

Aun así, creo que el trato compensa. Los atacantes que saben comparar árboles de código fuente se enteran del fallo en cuanto sale el parche, con anuncio o sin él; el preaviso solo cambia lo preparados que están los defensores en ese momento. Y la redacción del CERT-EU es condicional por algo. El aislamiento es el último recurso para una máquina que no puedes parchear, lo cual ya es reconocer que el verdadero fallo ocurrió meses antes, cuando nadie se hizo cargo de esa máquina. El pánico de aquel canal de Slack venía de no saber responder a una pregunta aburrida: cuáles de nuestros servidores pueden recibir hoy una build nueva de PHP.

Así que esto es lo que yo cambiaría, y es poca cosa. Trata el binario de PHP como una dependencia con lockfile. Fíjalo en la imagen base de tu contenedor o en tu configuración de aprovisionamiento, mételo en el mismo flujo de pull requests que todo lo demás y deja que tu CI pase la batería de tests contra la siguiente versión de parche el mismo día que aparezca. Si tu stack es Docker, es cambiar una línea del FROM y ver el pipeline en verde. Si es hosting compartido, es un acuerdo por escrito sobre la rapidez con la que el proveedor publica builds de seguridad, y ese acuerdo tiene que ir en el contrato junto a la cifra de disponibilidad. Nada de esto es glamuroso, y precisamente de eso se trata: el 21 de octubre, los equipos que lo tenían hicieron el despliegue antes de comer y volvieron a discutir sobre convenciones de nombres.

El aviso ya es público, así que ve a leer las versiones afectadas y corregidas en php.net y en tu distribución, y compáralas con lo que de verdad ejecutan tus servidores web. No repito aquí números de versión a propósito, porque la forma más rápida de difundir uno equivocado es una columna escrita de memoria. Lo que me importa es la próxima vez. Habrá otra versión de seguridad con fecha anunciada, y lo más probable es que el equipo de PHP vuelva a tener la cortesía de avisarnos.

Así que, con sinceridad: cuando llegue la próxima versión crítica anunciada de antemano, ¿cuántas horas tardarás en tener un runtime de PHP parcheado en todos los servidores de producción de los que eres responsable, y cuál es el paso más lento de toda esa cadena?