CVE-2026-59296

Micrometer StatsD and Logging meter registries line-protocol and log injection vulnerability

Published Aug 21, 2026 CVSS 3.1 · 5.9 Medium EPSS < 1% KEV · Not listed
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.
Micrometer 1.17.0
Micrometer 1.16.0 - 1.16.6
Micrometer 1.15.0 - 1.15.12
Micrometer 1.14.0 - 1.14.16
Micrometer 1.9.18 and earlier

Analysis

AI-generated

Technical impact

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. In Micrometer, when such input is passed freely, newline or carriage‑return characters can be injected into the StatsD line protocol or log output. This allows an attacker to break expected line boundaries, creating forged metric definitions or arbitrary log lines that can be interpreted as legitimate by downstream collectors, dashboards, or alerting systems. The vulnerability affects Micrometer releases 1.17.0, 1.16.0–1.16.6, 1.15.0–1.15.12, 1.14.0–1.14.16, and any version 1.9.18 or earlier.

Affected Systems

The vulnerability targets Spring Micrometer products, specifically the micrometer‑registry‑statsd and micrometer‑core libraries. All releases that lack newline sanitization are affected. Applications that employ the Datadog or Etsy flavors of the StatsD registry or the LoggingMeterRegistry and use user‑controlled data for metric names, tag keys, or tag values are directly at risk.

Risk and Exploitability

The CVSS score of 5.9 places the flaw in the medium‑severity range. The EPSS score of < 1% indicates a very low exploitation probability, and the vulnerability is not listed in the CISA KEV catalog. The likely attack vector, inferred from the CVE title and CWE identifiers, involves the injection of newline or carriage‑return characters into metric names, tag keys, or tag values supplied by an attacker. This can subvert metric namespaces or log content, resulting in misleading dashboards, false alarms, or cover‑up of malicious actions.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade micrometer‑registry‑statsd and micrometer‑core to the latest releases that sanitize newline characters
  • Validate or sanitize all user‑controlled inputs used as metric names, tag keys, or tag values, ensuring that any \n or \r characters are removed or escaped
  • If an immediate upgrade is impossible, replace the StatsD or LoggingMeterRegistry components with a safer equivalent and actively monitor log files for suspicious entries

Generated by OpenCVE AI on August 28, 2026 at 20:21 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories available
History
Type Values Removed Values Added
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. 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. Micrometer 1.17.0 Micrometer 1.16.0 - 1.16.6 Micrometer 1.15.0 - 1.15.12 Micrometer 1.14.0 - 1.14.16 Micrometer 1.9.18 and earlier
Type Values Removed Values Added
Weaknesses CWE-20
CWE-532
Type Values Removed Values Added
Weaknesses CWE-74
Type Values Removed Values Added
First Time appeared Spring
Spring micrometer
Vendors & Products Spring
Spring micrometer
Type Values Removed Values Added
Weaknesses CWE-20
CWE-532
Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Type Values Removed Values Added
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.
Title Micrometer StatsD and Logging meter registries line-protocol and log injection vulnerability
References
Metrics cvssV3_1

{'score': 5.9, 'vector': 'CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N'}

Weaknesses
  • CWE-74

    Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')

  • CWE-93

    Improper Neutralization of CRLF Sequences ('CRLF Injection')

Sources

Status
PUBLISHED
Assigner
vmware
Published
Updated
Aug 27, 2026, 5:57 PM
Reserved
Jul 4, 2026, 6:13 PM
Status
Awaiting Analysis
Published
Aug 21, 2026, 11:17 AM
Modified
Oct 16, 2026, 3:10 PM
Severity
Moderate
Public date
Aug 21, 2026, 10:47 AM