Primero, las versiones: 8.5.11, 8.4.26, 8.3.35, 8.2.34. Son las releases que una publicación muy compartida en Medium señalaba como portadoras de la corrección para CVE-2026-109618 y CVE-2026-109619, un fallo de seguridad de memoria en el código de progreso de subida de sesiones al que asignaba un CVSS v4.0 de 9.2, explotable sin autenticación con la configuración por defecto. El parche estaba previsto para el 2026-10-21 a las 14:00 UTC, una semana antes de que escriba esto. Antes de hacer nada más, compara el changelog oficial de php.net y el tracker de seguridad de tu distro con lo que tienes realmente instalado, porque una entrada de blog sirve para ponerte en alerta, pero la fuente de verdad es el aviso de seguridad oficial.

session.upload_progress.enabled = Off

Si estás en una de esas builds, bien. Has cerrado este agujero en concreto. Lo que me preocupa es el paso que la mayoría daremos a continuación: borrar discretamente la línea de emergencia del php.ini porque el ticket del incidente está cerrado y la línea parece un andamio. Yo defiendo lo contrario. Esa medida provisional fue el cambio más útil que recibieron tus servidores en todo el mes, y la actualización solo la ha vuelto opcional.

Pregúntate cuándo fue la última vez que publicaste una funcionalidad que dependiera de session.upload_progress. Revisé los cuatro repositorios con los que trabajo habitualmente, uno de ellos una app de Laravel que nació en 2016, y encontré cero lecturas de la clave de progreso en la sesión. Todas nuestras barras de progreso de subida salen del navegador, donde los eventos de subida de XHR o fetch informan de los bytes enviados sin que el servidor tenga que guardar ningún estado. Mientras tanto, la funcionalidad del lado del servidor ha estado activada por defecto en cada pool de FPM, analizando cada petición multipart por si alguien la quería.

Esa es la verdadera forma de este incidente. El código al que nadie llama se ejecuta igual si una opción por defecto lo activa, y el código que se ejecuta puede romperse. Un bug de un framework o un CMS se puede parchear en userland; un bug del núcleo como este alcanza por igual a WordPress, Drupal, tu API casera y esa herramienta interna olvidada, y a falta de la corrección, la única palanca que tienes es la configuración. Las ramas antiguas lo empeoran: el aviso indica que 8.0, 8.1 y todo lo de 7.x y 5.x no reciben nada, así que en esos hosts desactivar la función no es una medida provisional, es toda la defensa.

Ahora, la objeción justa. El progreso de subida existe por algo: funcionaba antes de que los navegadores expusieran los eventos de subida de forma fiable, y algunas apps veteranas, sobre todo las que tienen paneles de administración renderizados en servidor y un endpoint de polling, todavía dependen de él. Desactivarlo globalmente puede romper en silencio una barra de progreso de la que depende algún cliente, y nadie quiere un cambio de seguridad que aparezca como ticket de soporte a las 23:40 de un viernes. También hay un argumento razonable de que la solución correcta está en el núcleo, y de que los equipos de operaciones no deberían tener que cuestionar cada valor por defecto que distribuye php-src.

Las dos cosas son ciertas, y ninguna cambia mi conclusión. Aquí la rotura es barata de detectar, porque un grep de la clave de progreso de sesión en tus repositorios lleva un minuto, y las apps que la necesiten pueden volver a activarla en la configuración de su propio pool con un comentario que explique por qué. Eso invierte la carga: es la funcionalidad la que tiene que justificar estar activada, no tú quien tiene que justificar desactivarla. En cuanto a los valores por defecto del núcleo, me encantaría que php-src reconsiderara este, pero cambiar un valor por defecto tan asentado es un trabajo lento y cuidadoso por buenas razones, y tus servidores no tienen por qué esperar a que termine esa conversación.

Lo mismo vale para lo demás que sugería ese aviso y que quizá añadiste en pleno pánico: open_basedir por pool, una lista de disable_functions, alertas cuando los workers de FPM mueren con la señal 11. Nada de eso detiene a un atacante decidido, y el propio artículo lo reconoce. Pero un worker caído que aparece en tus logs en cuestión de minutos es el tipo de alerta temprana que rara vez tienes, y un pool que no puede ver fuera de su propio directorio convierte una mala noche en una noche manejable. Mantén las defensas aburridas cuando haya pasado la emoción.

Así que esto es lo que de verdad quiero saber en los comentarios: ¿alguien sigue usando a propósito session.upload_progress del lado del servidor en producción, y qué haría falta para que movieras esa barra de progreso al cliente? Si respondemos suficientes, quizá tengamos los datos para llevarle a php-src la propuesta de cambiar el valor por defecto.