Introduction
Micrometer is the default metrics instrumentation library in every Spring Boot application that has Actuator enabled. It contains a denial-of-service flaw that lets unauthenticated attackers exhaust server resources with specially crafted HTTP requests. Spring Boot is the dominant Java application framework in enterprise environments, so the blast radius of CVE-2026-40984 covers financial services, healthcare, government, and nearly any organization that runs JVM workloads with observability enabled.
Micrometer is a vendor-neutral metrics collection facade for JVM applications. Code is instrumented once, and the metrics can be exported to Prometheus, Datadog, Influx, and other backends. VMware describes it as "the gold standard in observability," and as the default metrics layer in Spring Boot it has an enormous installed base. Any Spring Boot application with metrics enabled uses Micrometer automatically, which makes this vulnerability relevant to a large part of the Java ecosystem.
Technical Information
CVE-2026-40984 is classified under CWE-400: Uncontrolled Resource Consumption. This is a weakness where a product fails to properly control the allocation and maintenance of limited resources such as memory, CPU cycles, or connections. CWE-400 is a consistent entry on the CWE Top 25 Most Dangerous Software Weaknesses list, a sign of how severe and how common it is in real-world software.
Root Cause
The vulnerability is in Micrometer's HTTP server instrumentation layer. When the instrumentation modules process incoming HTTP requests to record metrics, they do not properly bound resource consumption for certain crafted inputs. According to the Spring advisory, an application is vulnerable when all three of the following conditions are true:
- The application uses a vulnerable version of
io.micrometer:micrometer-core,micrometer-jetty11, ormicrometer-jetty12 - The HTTP server instrumentations are configured
- Metrics are being recorded
Three artifacts are affected. The micrometer-jetty11 and micrometer-jetty12 modules instrument the Jetty 11.x and Jetty 12.x HTTP servers respectively, so any Spring Boot or JVM application that runs Jetty as its embedded server with Micrometer metrics enabled is potentially exposed. The micrometer-core artifact provides the base instrumentation that both Jetty modules build on.
CVSS v3.1 Vector Analysis
The CVSS vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H gives a base score of 7.5 (HIGH). The components break down as follows:
| Component | Value | Implication |
|---|---|---|
| Attack Vector | Network | Exploitable remotely over the network |
| Attack Complexity | Low | No specialized conditions required |
| Privileges Required | None | No authentication needed |
| User Interaction | None | No user action required |
| Scope | Unchanged | Impact limited to the vulnerable component |
| Confidentiality | None | No information disclosure |
| Integrity | None | No data modification |
| Availability | High | Complete denial of service |
The notable combination is remote network access, no authentication, and complete availability impact. The only mitigating factor in the scoring is that the flaw affects availability alone. Confidentiality and integrity are not compromised.
Attack Flow
An attacker can exploit the vulnerability in this sequence:
- Identify a target service that uses Micrometer HTTP server instrumentation (any Spring Boot application with Actuator metrics and Jetty, or any JVM application using the affected Micrometer modules directly)
- Send specially crafted HTTP requests to the service endpoint
- The Micrometer instrumentation layer processes the request metadata for metrics collection
- The crafted input triggers uncontrolled resource consumption within the instrumentation code
- Server resources are exhausted, causing a denial of service
No authentication, special timing, or user cooperation is needed. A single properly crafted HTTP request can trigger the resource consumption.
Relationship to CVE-2026-40983
CVE-2026-40983, published the same day (June 8, 2026), is a parallel DoS vulnerability in Micrometer's gRPC server instrumentation. Both CVEs are classified as CWE-400, and both were discovered by the same researcher, Yu Bao (@August829) from PayPal. The same-day disclosure of two related DoS flaws in different Micrometer instrumentation modules reveals a systemic weakness in how the instrumentation layer handles request metadata for metrics collection. The original implementation did not adequately bound resource consumption across multiple protocol handlers.
Organizations should assess both CVEs at the same time. Patching one and not the other leaves residual DoS exposure.
Affected Systems and Versions
The vulnerability affects three Micrometer artifacts across several version branches:
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
- 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
- 1.13.0 through 1.13.18
micrometer-jetty12:
- 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
The micrometer-core artifact has the widest affected surface. It spans five major version branches, including the older 1.9.x line, while the Jetty modules are affected across four (1.13.x through 1.16.x). That spread indicates the underlying flaw has been in Micrometer's HTTP server instrumentation for a long time.
Fixed Versions and Availability
| Branch | Fixed Version | Availability |
|---|---|---|
| 1.16.x | 1.16.6 | All OSS users |
| 1.15.x | 1.15.12 | All OSS users |
| 1.14.x | 1.14.16 | VMware Tanzu Spring Enterprise only |
| 1.13.x | 1.13.19 | VMware Tanzu Spring Enterprise only |
| 1.9.x | 1.9.18 | VMware Tanzu Spring Enterprise only |
The Spring advisory confirms that the version upgrade is enough and no configuration changes are necessary. Organizations on the 1.14.x, 1.13.x, or 1.9.x branches have two choices. They can buy VMware Tanzu Spring Enterprise support to get the patch, or they can migrate to a supported OSS branch (1.15.x or 1.16.x). This two-tier remediation creates cost pressure for organizations on older branches, which are often the ones with the most cautious change management policies.
Vendor Security History
The Spring ecosystem has had several security vulnerabilities in 2026. That reflects both the breadth of its codebase and the scrutiny it gets as a widely deployed platform:
| CVE | Product | Severity | Description |
|---|---|---|---|
| CVE-2026-40984 | Micrometer HTTP server | HIGH (7.5) | DoS via crafted HTTP requests |
| CVE-2026-40983 | Micrometer gRPC server | HIGH | DoS via gRPC instrumentation |
| CVE-2026-41842 | Spring Framework | Unspecified | DoS via static resource resolution |
| CVE-2026-40973 | Spring Boot | Unspecified | Predictable temp directory accepted |
| CVE-2026-22732 | Spring Security | Unspecified | HTTP security header bypass |
| CVE-2025-41243 | Spring Cloud Gateway | CVSS 10.0 | Critical vulnerability in Server WebFlux |
The CVSS 10.0 critical vulnerability in Spring Cloud Gateway shows that the Spring ecosystem is not immune to severe security flaws. Two Micrometer DoS CVEs landing on the same day suggests the instrumentation layer had not been thoroughly audited for resource consumption before Yu Bao's discovery. Micrometer keeps a dedicated GitHub repository for security advisories at micrometer-metrics/security-advisories, and the Spring team publishes all advisories on spring.io/security.
References
- Spring Advisory: CVE-2026-40984
- Spring Security Advisories
- Canadian Centre for Cyber Security Advisory AV26-558
- CWE-400: Uncontrolled Resource Consumption
- CISA Known Exploited Vulnerabilities Catalog
- Micrometer Documentation
- Micrometer Application Observability
- Micrometer Security Advisories (GitHub)
- Spring Boot Metrics Documentation
- Micrometer: The Gold Standard in Observability (VMware Tanzu)
- VulnCheck: Quantifying 2026 Routinely Targeted Vulnerabilities
- Proofpoint: 2026 Vulnerability Exploitation in the Wild
- Broadcom VMware Acquisition (Form 8-K)
- VMware Tanzu: Various Spring Products Are Attackable (Heise)
- IBM Security Bulletin: VMware Tanzu Spring Framework Vulnerabilities



