Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-08-21T11:17:05.780Z",
  "pubdate": "2026-08-21T11:17:05.780Z",
  "executiveSummary": "An injection vulnerability exists in io.micrometer:micrometer-registry-statsd and io.micrometer:micrometer-core due to the lack of default sanitization for newline characters in untrusted metrics data.\nThe impact allows attackers to perform cross-metric spoofing, log forging, and metric injection across the metrics registry namespace.\nAffected systems include applications using vulnerable versions of io.micrometer:micrometer-registry-statsd with Datadog or Etsy flavors, or applications utilizing LoggingMeterRegistry.\nThe risk implications include data integrity compromise of monitoring systems and log poisoning, potentially blinding security operations or generating false telemetry.\nAttacker capabilities require the ability to supply untrusted, non-normalized input that gets used directly for metric names, tag keys, or tag values without validation.\nExploitation requires the application to instrument meters using user-controlled input while employing vulnerable registry configurations or logging meter implementations.",
  "technicalDetails": "The root cause of the vulnerability stems from the use of untrusted, non-normalized input as-is for metrics data, specifically metric names, tag keys, and tag values, without stripping or escaping newline characters such as \\n and \\r.\nThe vulnerable components include io.micrometer:micrometer-registry-statsd when configured with the Datadog or Etsy flavor, and io.micrometer:micrometer-core when utilizing LoggingMeterRegistry.\nBecause the StatsD protocol utilized by the Datadog and Etsy flavors is newline-delimited, failing to sanitize line terminators allows for line-protocol injection and cross-metric spoofing.\nSimilarly, because LoggingMeterRegistry prints metric output line-by-line to log files, unvalidated newline characters allow metric spoofing for downstream log-metrics scrapers or parsers, as well as general log spoofing.\nThe attack flow proceeds as follows: 1) An attacker supplies malicious input containing injected line terminators (\\n or \\r) via user-controlled parameters that feed into instrumentation code. 2) The application passes this unvalidated data directly to vulnerable Micrometer components as metric names, tag keys, or tag values. 3) During metric emission or logging, the injected newline characters prematurely terminate the current metric or log line. 4) The remaining injected payload is interpreted by the StatsD daemon or downstream log scrapers as a completely separate, arbitrary metric record or log entry.\nThis payload behavior enables attackers to spoof arbitrary metrics such as system load, standard Java Virtual Machine (JVM) metrics, or critical business metrics, completely subverting monitoring accuracy without requiring authentication or specific privileges beyond supplying untrusted input to the application."
}