CVE-2026-59296: Micrometer StatsD and Logging meter registries line-protocol and log injection vulnerability
Using untrusted, non-normalized input as-is for metrics data (such as metric names, tag keys, or tag values) is a dangerous antipattern that general-purpose instrumentation should never perform. When such unsafe instrumentation is used, the application becomes vulnerable to injection and spoofing attacks because micrometer-registry-statsd and micrometer-core do not sanitize newline characters (\n, \r) by default prior to this fix.
For the StatsD registry in micrometer-registry-statsd (when using the Datadog or Etsy flavor), because the StatsD protocol is newline-delimited, this allows for line-protocol injection (cross-metric spoofing). For LoggingMeterRegistry in micrometer-core, because metric output is printed line-by-line to log files, this allows for both metric spoofing (if downstream log-metrics scrapers or parsers ingest the log lines as separate metrics) and general log spoofing.
Specifically, an application is vulnerable when all the following are true:
The application uses a vulnerable version of io.micrometer:micrometer-registry-statsd or io.micrometer:micrometer-core. The application uses the Datadog or Etsy flavor of the StatsD registry, or uses LoggingMeterRegistry. The application instruments meters using user-controlled, unvalidated input for metric names, tag keys, or tag values.
When vulnerable, an attacker can break out of the current metric or log line by injecting line terminators. This allows them to spoof arbitrary metrics (e.g., system load, standard JVM metrics, or other business metrics) across the metrics registry namespace (either directly via StatsD protocol or via downstream log-metric scrapers/parsers), as well as inject arbitrary log entries to spoof general log records.
Affected Software
Event History
Frequently Asked Questions
Which deployments are affected?
Affected deployments use a vulnerable version of micrometer-registry-statsd with the Datadog or Etsy flavor, or use LoggingMeterRegistry from micrometer-core. Exploitation also requires unsafe instrumentation that passes untrusted, non-normalized data into metric names, tag keys, or tag values.
What must an attacker control to exploit this issue?
An attacker must be able to influence metric data that is used as a metric name, tag key, or tag value and have newline characters included in that data. Before the fix, newline characters are not sanitized by default.
What is the impact for each affected registry?
With the Datadog or Etsy StatsD flavors, newline-delimited protocol handling permits injected metric lines and cross-metric spoofing. With LoggingMeterRegistry, injected lines can spoof metrics for downstream log-metric parsers and can also spoof general log output.
What can be done before patching is available?
Do not use untrusted input directly as metric names, tag keys, or tag values. Normalize or reject newline characters in such input, and avoid unsafe instrumentation paths that allow externally influenced values to be emitted as metrics or log lines.