Introducción
En Five Cents, PHP bajo alerta crítica, explicamos qué hay que comprobar para que una actualización de seguridad proteja realmente el servidor. Veremos qué corrigen los parches de octubre, por qué apareció una mitigación adicional y cómo verificar versiones, configuración y procesos. El punto de partida es distinguir dos cosas que no son intercambiables: instalar una corrección y desactivar temporalmente una vía de ataque.
Qué está pasando
Una ejecución remota de código sin autenticación significa que un atacante podría conseguir que el servidor ejecutara instrucciones sin iniciar sesión. No hablamos solamente de bloquear una página. El alcance dependería de los permisos del proceso comprometido. Por eso importa que el problema pueda aparecer antes de que la aplicación aplique sus propias comprobaciones.
Ese es el riesgo descrito en los dos fallos corregidos el veintiuno de octubre de dos mil veintiséis. Uno afecta a la gestión de errores cuando falta memoria. El otro permite utilizar un estado interno que debería haberse descartado entre peticiones atendidas por un mismo proceso trabajador. Esos procesos, también llamados workers, atienden sucesivas solicitudes web.
El aviso sitúa el mayor riesgo en Apache con mod_php, donde se demostró una explotación anterior a la ejecución del código de la aplicación. Eso no permite concluir que cualquier otra modalidad esté a salvo. La revisión debe abarcar también PHP-FPM, PHP-CGI y los entornos empaquetados por terceros.
Las versiones señaladas como corregidas son la ocho punto cinco punto doce, la ocho punto cuatro punto veintisiete, la ocho punto tres punto treinta y seis y la ocho punto dos punto treinta y cinco. Pero comprobar un número no siempre resuelve la pregunta. Una distribución puede mantener una versión anterior e incorporar el arreglo a su paquete.
En ramas antiguas, especialmente PHP ocho punto uno y anteriores, hay que confirmar qué cobertura ofrece el proveedor y si incluye estas correcciones. La antigüedad aparente del número no demuestra por sí sola ni protección ni vulnerabilidad.
La situación añadió otro elemento el veintitrés de octubre
La situación añadió otro elemento el veintitrés de octubre: un aviso sobre un vector distinto, todavía sin corrección específica publicada en el momento descrito. Aquí la condición es mucho más concreta. El sistema debe utilizar uno de dos formatos de serialización de sesiones, php_binary o php_serialize; la aplicación debe cambiarlo a php antes de iniciar la sesión; y el seguimiento del progreso de cargas debe seguir activado.
La serialización es la forma de convertir los datos de una sesión en un formato que pueda guardarse y recuperarse. Lo relevante en este caso es el cambio de formato durante la petición, combinado con esa función de seguimiento. Es una configuración inusual. No significa que todos los servidores actualizados sigan expuestos, ni que los parches anteriores sean inútiles.
La mitigación recomendada consiste en desactivar session.upload_progress.enabled, asignándole el valor cero. Tiene que hacerse en una configuración del servidor o del pool que se aplique antes de procesar la petición. No basta con cambiarlo desde el código mediante ini_set, ni con confiar en un archivo de configuración por directorio, conocido como punto user punto ini.
Después hay que reiniciar los procesos trabajadores para que incorporen el ajuste. ¿Cómo convertir esto en una comprobación operativa? Primero, hay que localizar lo que realmente recibe tráfico. Un servidor puede tener varias instalaciones de PHP, y la versión que aparece en la terminal puede no coincidir con la que utiliza la web. También cuentan los contenedores, las imágenes de despliegue y los productos que incluyen su propio entorno de ejecución.
Después toca verificar cada servicio: qué paquete utiliza, si incorpora la corrección y si sus procesos se han renovado. En alojamiento gestionado, la pregunta al proveedor debe ser concreta: si aplicó los arreglos, cómo cubre el aviso adicional y si reinició los procesos afectados. Una confirmación genérica de que el alojamiento está actualizado aporta menos información.
Por qué importa
Conviene revisar también si el código cambia session.serialize_handler antes de llamar a session_start. Esa comprobación ayuda a determinar si se cumple la combinación descrita. Y si la aplicación utiliza el seguimiento de cargas, desactivarlo exige comprobar qué función deja de estar disponible durante la mitigación.
Los servicios accesibles desde Internet tienen prioridad. Si no es posible corregir o mitigar uno de ellos y verificar el resultado, puede ser necesario aislarlo temporalmente hasta resolverlo. Además, actualizar el contenedor activo sin corregir la imagen de despliegue permite que una recreación posterior recupere el problema. La revisión debe cubrir ambos.
En resumen: los parches corrigen los fallos iniciales; la mitigación adicional responde a una combinación específica; y la protección debe comprobarse en los procesos que atienden las peticiones, no solo en los paquetes instalados.
Para seguir con estas comprobaciones, puedes generar dos nuevos Five Cents: Verificar PHP-FPM después de actualizar y Gestionar imágenes de contenedores vulnerables. Ya estás al día en cinco minutos.