CVE-2026-59296 in Spring Micrometer
Summary
by MITRE • 08/21/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/21/2026
The vulnerability described involves a critical input validation flaw within the Micrometer instrumentation library, specifically affecting the io.micrometer:micrometer-registry-statsd and io.micrometer:micrometer-core components prior to their respective patches. This issue stems from an antipattern where untrusted or non-normalized user-controlled data is directly utilized as metric metadata without adequate sanitization. In secure software architecture, any input derived from external sources that influences system behavior must be strictly validated against a whitelist of allowed characters and formats. The failure to enforce this principle in the context of metrics generation creates significant security risks related to injection and spoofing attacks.
The technical root cause lies in the handling of newline characters within specific registry implementations. For applications utilizing the StatsD registry with either the Datadog or Etsy flavor, the underlying protocol relies on newline-delimited lines to transmit metric data. Because the vulnerable versions do not sanitize carriage return (\r) and line feed (\n) characters by default, an attacker can inject these terminators into metric names, tag keys, or tag values. This allows for line-protocol injection, effectively breaking out of the intended single-line structure of a specific metric entry. Similarly, in the LoggingMeterRegistry component found within micrometer-core, metrics are output as individual lines to log files. The absence of newline sanitization here permits both metric spoofing and general log spoofing, depending on how downstream systems process these logs.
The operational impact of this vulnerability is severe due to its potential for data integrity compromise and security monitoring evasion. In the context of StatsD registries, an attacker can inject arbitrary metrics into the telemetry stream. This capability enables cross-metric spoofing, where malicious actors can fabricate entries that mimic legitimate system indicators such as CPU load, memory usage, or JVM statistics. By injecting false high-load metrics, attackers might trigger automated scaling events causing denial of service through resource exhaustion, or conversely inject low values to mask ongoing attacks from monitoring systems. In the context of LoggingMeterRegistry, the impact extends beyond metric falsification to include log injection. If downstream parsers ingest these logs as separate metrics, they can be tricked into processing fabricated data points. Furthermore, if the logging infrastructure is used for security auditing or incident response, injected malicious log entries can obscure real attack traces or create false positives that distract security operations teams.
This vulnerability aligns with CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component and CWE-1389 Malicious Data Parsing. From an offensive perspective, it relates to ATT&CK technique T1562 Impair Defenses via Obfuscation or Injection, as attackers can manipulate the data stream used for defense monitoring. The attack vector typically requires initial access to inject user-controlled input into instrumented code paths, which may be achieved through web application inputs, API parameters, or message queue payloads that feed into monitored services.
Mitigation strategies must prioritize immediate patching and architectural review. Organizations should upgrade io.micrometer:micrometer-registry-statsd and io.micrometer:micrometer-core to the latest patched versions where newline characters are automatically sanitized before transmission or logging. For environments unable to update immediately, developers must implement strict input validation on all metric names, tag keys, and values at the application layer. This involves filtering out control characters such as \n, \r, and other whitespace that could disrupt line-based protocols. Additionally, adopting a whitelist approach for allowed characters in metric identifiers can prevent injection attempts. Security teams should also monitor telemetry data streams for anomalies indicative of spoofing, such as sudden spikes in unique tag values or unexpected metric names originating from untrusted sources, to detect potential exploitation attempts even after remediation efforts are underway.