Spring Micrometer CVE-2026-59296

Exploitation requires all three of the following conditions to hold simultaneously. First, the application must use a vulnerable version of io.micrometer:micrometer-registry-statsd or io.micrometer:micrometer-core. Second, the application must be configured to use specifically the Datadog or Etsy flavor of the StatsD registry - not the Telegraf or other protocol flavors - or must use LoggingMeterRegistry for metric output. Third, and most critically, the application must construct meter names, tag keys, or tag values using user-controlled, unvalidated input: for example, passing an HTTP request header, query parameter, path variable, or externally sourced identifier directly into a meter tag without stripping control characters. Exploitation is bounded by: the AC:H multi-condition dependency; the requirement that Datadog/Etsy StatsD or LoggingMeterRegistry is actively deployed (not all Micrometer backends are affected); the need for user input to reach the instrumentation layer without prior input validation; and the integrity-only impact scope, which limits attacker objectives to metric and log spoofing rather than data exfiltration or service disruption.

The CVSS 3.1 score of 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N) appropriately reflects the multi-condition dependency: exploitation requires the Datadog or Etsy StatsD flavor or LoggingMeterRegistry to be configured, and user-supplied strings must flow unvalidated into meter tag fields - a high attack-complexity designation that keeps the score in the medium tier. However, the AC:H rating may understate practical exposure, because passing request-derived data into custom meter tags for high-cardinality observability is a common Spring Boot pattern, making the preconditions less exceptional than the score implies. The impact is integrity-only: no confidentiality breach and no availability degradation are achievable via this primitive, limiting attacker motivation to corrupting observability pipelines, suppressing genuine alerts, or injecting false log evidence. No EPSS data was present in the provided intelligence, and this CVE does not appear in the CISA KEV catalog, which aligns with a scenario of no confirmed widespread exploitation at time of analysis. The real-world risk is most acute for organizations whose security operations or SRE teams treat Micrometer-sourced telemetry as authoritative - even a mid-sized engineering department in a place like rybnik operating a Spring Boot microservices platform could find spoofed JVM or business metrics meaningful enough to delay or misdirect incident response - but the absence of active exploitation and the AC:H preconditions mean this is a patch-cycle priority rather than an emergency for most deployments.

An attacker sends an HTTP request whose path variable or query parameter - for example, a tenant identifier or user-agent string - is passed directly as a Micrometer tag value without sanitization. By embedding a literal \n character in that parameter, the attacker terminates the in-progress StatsD line and appends a fully formed fake metric line such as 'system.cpu.usage:0.00|g', which the Datadog or Etsy StatsD agent records as a legitimate application metric. No public exploit code has been identified at time of analysis, but the technique requires only standard HTTP tooling and knowledge of the application's meter tag structure.