CVE-2026-40984

Overview

Micrometer is a vendor-neutral application metrics facade for the JVM: instrumentation code records timers, counters and gauges against a MeterRegistry, and a registry implementation exports them to a monitoring backend. The affected module, micrometer-core, is the facade and the instrumentation itself, and it ships the server-side HTTP instrumentation that records a timer for every inbound request, tagged with the request method, URI and outcome.

A Denial of Service (DoS) vulnerability (CVE-2026-40984) has been identified in the server-side HTTP instrumentation of micrometer-core, which allows attackers to exhaust application memory by sending unauthenticated requests carrying arbitrary HTTP method tokens. Each distinct token becomes a new value of the method meter tag, and each new tag value creates a new time series that the meter registry retains for the lifetime of the process, so a modest volume of crafted requests drives unbounded meter cardinality until the JVM runs out of memory.

Per OWASP: The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed. There are many ways to make a service unavailable for legitimate users by manipulating network packets, programming, logical, or resources handling vulnerabilities, among others. If a service receives a very large number of requests, it may cease to be available to legitimate users. In the same way, a service may stop if a programming vulnerability is exploited, or the way the service handles resources it uses.

This issue affects the server-side HTTP instrumentation of Micrometer.

‍

Details

Module Info

• Product: Micrometer
• Affected packages: io.micrometer:micrometer-core
• Affected versions: 1.16.0 to 1.16.5, 1.15.0 to 1.15.11, 1.14.0 to 1.14.15, 1.10.0 to 1.13.18, and 1.9.17 and earlier
• GitHub repository: https://github.com/micrometer-metrics/micrometer
• Published packages: https://central.sonatype.com/artifact/io.micrometer/micrometer-core
• Package manager: Maven
• Fixed in:
• NES lines: NES for Micrometer 1.9.x
• OSS versions: Micrometer 1.15.12 and 1.16.6

Vulnerability Info

This High-severity vulnerability is found in the micrometer-core package in the server-side HTTP instrumentation of Micrometer.

The instrumentation derives the method meter tag straight from the request line. HttpRequestTags.method accepts whatever token the client sent and wraps it in a tag without checking it against the set of methods HTTP actually defines:

public class HttpRequestTags {

    private static final Tag METHOD_UNKNOWN = Tag.of("method", "UNKNOWN");

    /**
     * Creates a {@code method} tag based on the {@link HttpServletRequest#getMethod()
     * method} of the given {@code request}.
     * @param request the request
     * @return the method tag whose value is a capitalized method (e.g. GET).
     */
    public static Tag method(HttpServletRequest request) {
        return (request != null) ? Tag.of("method", request.getMethod()) : METHOD_UNKNOWN;
    }

The Jersey server instrumentation in the same package repeats the pattern against the Jersey container request:

    public static Tag method(ContainerRequest request) {
        return (request != null) ? Tag.of("method", request.getMethod()) : METHOD_UNKNOWN;
    }

Both are on the default request path rather than behind an opt-in. DefaultHttpServletRequestTagsProvider, the tags provider the Jetty TimedHandler installs when no custom provider is supplied, calls the servlet variant for every request it times:

    @Override
    public Iterable<Tag> getTags(HttpServletRequest request, HttpServletResponse response) {
        return Tags.of(HttpRequestTags.method(request), HttpRequestTags.status(response),
                HttpRequestTags.outcome(response));
    }

and DefaultJerseyTagsProvider, used by the Jersey MetricsRequestEventListener, calls the Jersey variant on both the request and long-request paths.

The method token is attacker-controlled and unauthenticated: servlet containers and Jersey pass through any syntactically valid token, so a request line such as AAAA1 /health HTTP/1.1 reaches the tag builder unchanged. Because the registry keys a distinct meter per distinct tag value set and never evicts those meters, every unique token permanently adds a time series holding its own counters, histograms and tag strings. An attacker who cycles the method token across requests grows that map without bound, driving heap exhaustion in the instrumented application and, downstream, a cardinality explosion in the monitoring backend the registry publishes to. No credentials, user interaction or special privileges are required, and the UNKNOWN fallback value already present in the code is only used when the request object itself is absent.

This vulnerability was introduced in 2020 with Micrometer 1.3.4.

‍

Mitigation

The affected 1.9.x and earlier release lines are End-of-Life and will not receive community updates addressing this issue.

Users of the affected components should apply one of the following mitigations:

• Upgrade Micrometer to a currently supported release containing the fix.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

‍

Credits

• Yu Bao from PayPal (finder)