CVE-2026-59296 in Spring Micrometer
Riassunto
di VulDB • 21/08/2026
L'utilizzo di input non attendibili e non normalizzati così come sono per i dati delle metriche (ad esempio, nomi di metrica, chiavi dei tag o valori dei tag) è una pratica antipattern pericolosa che l'instrumentation a scopo generale non dovrebbe mai eseguire. Quando viene utilizzata tale instrumentation insicura, l'applicazione diventa vulnerabile ad attacchi di iniezione e spoofing poiché micrometer-registry-statsd e micrometer-core non sanificano i caratteri di nuova riga (\n, \r) per impostazione predefinita prima della risoluzione del problema.
* Per il registry StatsD in micrometer-registry-statsd (quando si utilizza la flavor Datadog o Etsy), poiché il protocollo StatsD è delimitato da newline, ciò consente l'iniezione di line-protocol (spoofing cross-metric). * Per LoggingMeterRegistry in micrometer-core, poiché l'output delle metriche viene stampato riga per rigua nei file di log, ciò consente sia lo spoofing delle metriche (se gli scraper o parser di log-metrics a valle ingeriscono le righe di log come metriche separate) che il generale log spoofing.
Nello specifico, un'applicazione è vulnerabile quando sono vere tutte le seguenti condizioni:
* L'applicazione utilizza una versione vulnerabile di io.micrometer:micrometer-registry-statsd o io.micrometer:micrometer-core. * L'applicazione utilizza la flavor Datadog o Etsy del registry StatsD, oppure utilizza LoggingMeterRegistry. * L'applicazione instrumenta i meters utilizzando input controllato dall'utente e non validato per nomi di metrica, chiavi dei tag o valori dei tag.
Quando vulnerabile, un attaccante può uscire dalla riga corrente della metrica o del log iniettando terminatori di riga. Ciò consente loro di effettuare spoofing di metriche arbitrarie (ad esempio, carico di sistema, JVM standard metrics o altre business metrics) nell'namespace del registry delle metriche (sia direttamente tramite il protocollo StatsD che tramite scraper/parser di log-metrics a valle), nonché di iniettare voci di log arbitrarie per effettuare spoofing dei record di log generali.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.