Описание
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.
A flaw was found in Micrometer's StatsD and Logging meter registries. This vulnerability allows a remote attacker to inject line terminators into metric data, such as names or tag values, due to insufficient sanitization of untrusted input. Exploitation can lead to the spoofing of arbitrary metrics, including critical system or business metrics, and the injection of false log entries, potentially impacting monitoring and auditing systems.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Exploit Intelligence | exploit-intelligence/agent-client-rhel9 | Out of support scope | ||
| Red Hat AMQ Broker 7 | micrometer-core | Affected | ||
| Red Hat build of Apache Camel 4 for Quarkus 3 | micrometer-core | Affected | ||
| Red Hat build of Apache Camel for Spring Boot 4 | micrometer-core | Affected | ||
| Red Hat build of Apicurio Registry 3 | micrometer-core | Out of support scope | ||
| Red Hat build of Debezium 3 | micrometer-core | Affected | ||
| Red Hat Build of Keycloak | keycloak/rhbk-openshift-rhel9 | Affected | ||
| Red Hat Build of Keycloak | keycloak/rhbk-rhel9-operator | Affected | ||
| Red Hat Build of Keycloak | micrometer-core | Affected | ||
| Red Hat Build of Keycloak | rhbk/keycloak-rhel9 | Affected |
Показывать по
Дополнительная информация
Статус:
EPSS
5.9 Medium
CVSS3
Связанные уязвимости
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
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 ...
EPSS
5.9 Medium
CVSS3