CVE-2026-40984

What it actually does

CVE-2026-40984 is a network-exploitable denial-of-service flaw in Micrometer instrumentation components. An unauthenticated remote user can send specially crafted HTTP requests that cause affected Micrometer metric handling paths to consume excessive resources or otherwise degrade application availability. The impact is availability-only: the vulnerability is not described as enabling data disclosure, privilege escalation, or code execution, but it can make applications using affected Micrometer versions slow, unstable, or unavailable.

Why it matters to the business

Applications that depend on affected Micrometer versions may be disrupted by unauthenticated internet or internal network traffic, causing outages, degraded customer experience, missed service-level objectives, and increased operational load for engineering teams. The CVSS score is high for availability impact, but current exploitation signals are limited: EPSS is low and flat over the last 30 days, it is not listed in CISA KEV, and no mature public exploit is indicated. Organizations with many Java services or platform components using Micrometer should still prioritize remediation because Micrometer is commonly embedded as a transitive dependency in Spring and JVM application stacks.

How an attack unfolds

An attacker first identifies an HTTP service built with a vulnerable Micrometer dependency, often by targeting Java web applications that expose instrumented HTTP request metrics. The attacker then sends specially crafted HTTP requests designed to trigger the vulnerable metric-processing behavior. Because the flaw requires no authentication, no user interaction, and low attack complexity, exploitation can be attempted remotely against reachable services. Repeated or concurrent malicious requests can exhaust resources, block request processing, or destabilize the application, resulting in a denial-of-service condition. There is no evidence from the provided intelligence that exploitation leads to code execution or data theft.

How to fix it

Upgrade affected Micrometer packages to fixed releases when available from the vendor or maintainers. Review both direct and transitive dependencies for micrometer-core, micrometer-jetty11, and micrometer-jetty12. Affected ranges include micrometer-core 1.16.0 through 1.16.5, 1.15.0 through 1.15.11, 1.14.0 through 1.14.15, 1.13.0 through 1.13.18, and 1.9.0 through 1.9.17; micrometer-jetty11 1.16.0 through 1.16.5, 1.15.0 through 1.15.11, 1.14.0 through 1.14.15, and 1.13.0 through 1.13.18; and micrometer-jetty12 1.16.0 through 1.16.5, 1.15.0 through 1.15.11, 1.14.0 through 1.14.15, and 1.13.0 through 1.13.18. If immediate upgrade is not possible, reduce exposure by limiting access to affected HTTP services, applying rate limits, using WAF or reverse-proxy request filtering where a reliable request pattern is known, enforcing request-size and header-count limits, and ensuring autoscaling and health checks can recover failed instances. Also rebuild and redeploy applications after dependency updates, because Micrometer is often packaged inside application artifacts.

How to confirm the fix worked

Confirm exposure by generating a software bill of materials or dependency tree for each Java application and checking for affected versions of micrometer-core, micrometer-jetty11, and micrometer-jetty12, including transitive dependencies. For Maven, inspect `mvn dependency:tree`; for Gradle, inspect `gradle dependencies` or dependency-lock files; for containerized services, inspect packaged JARs and SBOM output. Validate remediation by confirming the vulnerable versions are no longer present in built artifacts, deployed containers, and runtime classpaths. Operationally, run regression and load tests against instrumented HTTP endpoints to confirm request metrics still function and that malformed or unusual requests do not cause abnormal CPU, memory, thread, latency, or restart behavior.

Typical attack path

1. Identify internet-facing or internally reachable Java HTTP services likely using Micrometer instrumentation.
2. Determine whether the service is running an affected Micrometer component or a framework version that bundles one.
3. Send specially crafted HTTP requests that exercise the vulnerable Micrometer request-metrics handling path.
4. Repeat or parallelize requests to amplify resource exhaustion or service instability.
5. Observe application slowdown, elevated error rates, failed health checks, container restarts, or service unavailability.

How to detect it

Look for signs of availability-focused exploitation rather than data access. Relevant sources include web server and reverse-proxy access logs, application logs, JVM logs, container orchestration events, APM metrics, load balancer health-check logs, and WAF logs. Investigate time windows where affected services show sudden increases in 4xx or 5xx responses, request latency, CPU saturation, memory pressure, garbage-collection pauses, thread exhaustion, failed health checks, pod or container restarts, or JVM termination errors. Correlate these events with bursts of unauthenticated HTTP requests from the same source, unusual request paths, abnormal header volume, oversized request components, malformed request syntax, or high-cardinality request patterns. Because no specific exploit payload or public IOC is provided, detections should focus on behavioral anomalies and runtime failure artifacts associated with Micrometer-instrumented HTTP request processing.

• java.lang.OutOfMemoryError
• java.lang.StackOverflowError
• java.lang.OutOfMemoryError: Java heap space
• java.lang.OutOfMemoryError: GC overhead limit exceeded
• java.lang.OutOfMemoryError: Metaspace
• java.lang.OutOfMemoryError: unable to create new native thread
• Application run failed
• Exception in thread
• io.micrometer
• micrometer-core
• micrometer-jetty11
• micrometer-jetty12
• Readiness probe failed
• Liveness probe failed
• Back-off restarting failed container
• CrashLoopBackOff
• HTTP 500
• HTTP 502
• HTTP 503
• HTTP 504

What your security team should do

• Inventory all Java services and shared platform components that include Micrometer, prioritizing internet-facing and high-availability services.
• Patch or rebuild applications using affected micrometer-core, micrometer-jetty11, or micrometer-jetty12 versions as part of the next urgent dependency update cycle.
• Treat transitive dependencies as in scope; do not rely only on top-level dependency declarations.
• Apply temporary compensating controls for exposed services, including rate limiting, request-size limits, header-count limits, reverse-proxy protections, and restricted network access.
• Monitor application availability signals for suspected exploitation, including sudden request latency spikes, elevated 5xx responses, CPU or memory exhaustion, JVM crashes, and container restart loops.
• Create SIEM detections for abnormal bursts of malformed or unusual HTTP requests correlated with Micrometer/JVM resource-exhaustion errors.
• Because EPSS is currently low and the CVE is not in KEV, prioritize by exposure and service criticality rather than emergency enterprise-wide shutdown, while still remediating promptly.