PHP 7.4.33 (cli). Apostaría a que ese banner sigue apareciendo esta semana en una cantidad alarmante de servidores de producción. La 7.4.33 fue la última versión que tuvo esa rama, y la línea 7.4 dejó de recibir parches de seguridad en noviembre de 2022. Ten presente esa cadena de versión mientras los titulares discuten sobre inteligencia artificial, porque es lo que decide si CVE-2026-109618 y CVE-2026-109619 te suponen un martes complicado o una notificación de brecha.

Esto es lo que se ha publicado. Hay dos fallos en el motor de PHP, con una puntuación de 9.2, que permiten ejecución remota de código sin autenticación. Al parecer los bugs tienen más de una década, y la corrección habría exigido un cambio importante en el propio motor. Los encontró Wiz junto con GPT-5.6 Sol de OpenAI, dentro de un programa llamado Patch the Planet. Palo Alto Networks cuenta más de 22,6 millones de instancias expuestas. Nicholas Weaver le dijo a Cybersecurity Dive que ya se ha visto explotación activa. Los detalles se filtraron en redes sociales un martes, así que la versión de emergencia salió un día antes de lo previsto. Finlandia desconectó sus servicios públicos estatales, la agencia nacional de ciberseguridad de Países Bajos tumbó su propia web, varias webs de prefecturas francesas estuvieron caídas un tiempo y Wikimedia perdió brevemente algunos sistemas. Te lo cuento tal como se ha publicado. Contrasta el aviso de php.net con tu propio stack antes de fiarte de cualquier resumen de segunda mano, incluido este.

La cifra a la que no dejo de volver no es la de 22,6 millones. Cisco calcula que aproximadamente la mitad de las instancias expuestas a internet corren versiones de PHP tan antiguas que ya no reciben ninguna actualización de seguridad. Para esos servidores, el parche de emergencia no existe. No va a llegar ninguna 7.2.35 a salvarlos. La única salida es saltar de versión, y saltar de versión en un código que nadie ha tocado desde 2019 es un proyecto, no un parche.

El argumento más sólido en mi contra es que lo de la IA sí es la noticia. Si un modelo puede destapar en unos pocos meses un fallo del motor de hace doce años, encontrar bugs se ha vuelto barato para todo el mundo, atacantes incluidos, y el margen entre la divulgación y la explotación va a seguir encogiéndose. Estoy de acuerdo. Solo que no creo que cambie la conclusión. Imagina este mismo bug encontrado a la antigua por un investigador humano. Los servidores atascados en ramas sin soporte estarían exactamente igual de expuestos, porque su problema nunca fue que nadie viera el agujero. Su problema es que ninguna corrección puede llegarles en menos de una semana. Que encontrar bugs salga más barato aprieta más sobre esa debilidad, pero la debilidad es otra.

Tampoco voy a fingir que actualizar sea fácil, porque he hecho suficientes migraciones como para saber dónde duele. Una aplicación heredada que depende de each() o create_function() se rompe directamente en PHP 8.0, porque ambas se eliminaron. La deprecación de las propiedades dinámicas en 8.2 te llena los logs de avisos que vienen de código de terceros que no escribiste y que no puedes forkear sin más. Y luego está la extensión compilada contra alguna ABI ya desaparecida que solo entendía una persona, y esa persona se fue en 2021. Decirle a un equipo que ha pasado por eso que simplemente actualice es un consejo barato. Aun así, un fin de semana de pasadas de Rector y fixtures rotas sale más barato que ser una de las webs que el gobierno tuvo que desenchufar.

Sinceramente, este es uno de los pocos frentes en los que nuestro ecosistema queda bien si lo miras con buenos ojos. El motor recibió una corrección profunda y delicada y la publicó antes de tiempo en plena filtración, y eso es un proyecto funcionando como debe. Donde todo se desmorona es aguas abajo: en imágenes de hosting que fijan versiones menores para siempre y en contratos de agencia que cubren construir la web pero nunca mantenerla. Una amiga que programa en Go suele recordarme que su despliegue es un único binario. Es verdad, y aun así la última vez que pasó algo parecido tuvo que recompilar y redesplegar todo lo que enlazaba con una librería vulnerable. Todos los lenguajes tienen este problema. El nuestro simplemente mueve una parte más grande de la web, así que lo vemos a mayor escala.

Así que la lección que yo sacaría de octubre no es que la IA dé miedo. Es que estar en una rama con soporte tiene que ser un requisito permanente, revisado con la misma frecuencia que las copias de seguridad, y no una esperanza que alguien aprueba durante una reescritura. Si tu servidor de producción más antiguo no puede pasar a una versión menor con soporte en la semana siguiente a un aviso, ese es tu riesgo real, lo encuentre quien lo encuentre o lo que lo encuentre.

Y aquí va lo que de verdad me gustaría que me contaras. ¿Qué tiene atado tu servidor de producción más antiguo a su versión actual de PHP: una extensión, una versión mayor del framework, un contrato con un cliente o simplemente que nadie se hace cargo de él? Y, siendo realista, ¿cuánto tardarías en llevarlo a una rama con soporte si el próximo aviso saliera mañana por la mañana?