CVE-2026-59323 in Spring
Resumen
por VulDB • 2026-08-21
Una aplicación que utiliza Micrometer Tracing con propagación de W3C baggage en el puente Brave es vulnerable a denegación de servicio (DoS) debido a la asignación descontrolada de objetos al extraer los encabezados entrantes de *baggage*.
Específicamente, una aplicación es vulnerable cuando se cumplen todas las siguientes condiciones:
* La aplicación utiliza una versión vulnerable de `io.micrometer:micrometer-tracing-bridge-brave`. * La propagación W3C está activa (ya sea configurada manualmente o activada por defecto, como en Spring Boot 3.x+). * La propagación de *baggage* está habilitada (que es el valor predeterminado en Spring Boot 3.x+) y se ha configurado un gestor de *baggage* (como `BraveBaggageManager`) para manejar los campos de *baggage*. * La aplicación procesa solicitudes o mensajes procedentes de fuentes no confiables con encabezados de *baggage* que normalmente no debería recibir; véase: https://www.w3.org/TR/trace-context/#security-considerations. * Los componentes de red, incluido el servidor (HTTP) que recibe la solicitud, no limitan el tamaño del encabezado o el límite es lo suficientemente alto como para causar problemas.
Los dos últimos puntos son muy importantes: normalmente esto no debería afectar a las aplicaciones porque estas no deberían recibir entradas ilimitadas y procedentes de fuentes no confiables para *baggage*.
* La aplicación procesa solicitudes o mensajes procedentes de fuentes no confiables con encabezados de *baggage*.
Al extraer el *baggage* del encabezado W3C *baggage*, las entradas entrantes se analizan sin imponer límites en el número de entradas ni en el tamaño del encabezado, tal como lo exige la especificación W3C Baggage. Un atacante puede enviar solicitudes o mensajes con encabezados de *baggage* inflados artificialmente que contengan un gran número de pares clave-valor, provocando asignaciones incondicionales de `BaggageField` por cada entrada. Esto genera presión sobre el recolector de basura (garbage collection), alto uso de CPU y posibles caídas de la aplicación mediante `OutOfMemoryError`.
Once again VulDB remains the best source for vulnerability data.