CVE-2026-40983: Micrometer gRPC Denial-of-Service Vulnerability

Technical summary

The vulnerability exists in Micrometer versions 1.16.0–1.16.5 and 1.15.0–1.15.11 and stems from improper handling of gRPC protocol input (CWE-400: Uncontrolled Resource Consumption; CWE-770: Allocation of Resources Without Limits or Throttling). By crafting malicious gRPC requests, an attacker can trigger resource exhaustion or infinite loops that crash the instrumented service. The attack requires no authentication or user interaction and can be executed over the network, making it trivially exploitable by any attacker with network visibility to an affected endpoint.

Business impact

Organizations using vulnerable versions face service disruption and potential cascading failures in microservices architectures that depend on Micrometer for observability. If your platform ingests metrics from multiple instrumented services, a DoS attack on one service's metrics pipeline could degrade visibility into your entire infrastructure during an incident—precisely when you need observability most. In production environments running containerized workloads, this could trigger rapid pod cycling and orchestration churn, compounding availability damage.

Affected systems

Micrometer 1.16.0 through 1.16.5 and 1.15.0 through 1.15.11 are vulnerable. This includes any application that embeds these library versions, particularly microservices using Spring Boot, Quarkus, Helidon, or other frameworks that depend on Micrometer for metrics collection and export. Confirm your dependency tree; Micrometer is often a transitive dependency pulled in by observability stacks. Versions prior to 1.15.0 and 1.16.0, as well as versions 1.16.6+ and 1.15.12+ (when released), are not affected.

Exploitability

Exploitability is straightforward: the attack vector is network-accessible (AV:N), requires no special conditions (AC:L), no privileges (PR:N), and no user interaction (UI:N). Any network endpoint exposing gRPC services instrumented with vulnerable Micrometer versions can be targeted by an attacker with basic knowledge of gRPC protocol construction. Public exploit code has not been reported as of the advisory date, but the attack surface is well-defined and does not require sophisticated techniques.

Remediation

Upgrade Micrometer to version 1.15.12 or later (for the 1.15.x line) or 1.16.6 or later (for the 1.16.x line). Patch your applications and redeploy; Micrometer is typically updated via Maven, Gradle, or other dependency managers. If immediate patching is not feasible, isolate gRPC endpoints from untrusted networks using firewall rules or service-mesh policies, though this is a temporary measure and patches should be prioritized. Verify compatibility with your frameworks before deploying—consult the Micrometer release notes for any breaking changes.

Patch guidance

1. Audit your dependency manifests (pom.xml, build.gradle, requirements files) to identify all services using Micrometer 1.15.0–1.15.11 or 1.16.0–1.16.5. 2. Update to the fixed versions (1.15.12+ or 1.16.6+) in your dependency manager. 3. Run your build pipeline and integration tests to confirm compatibility. 4. Deploy updates to development and staging environments first, then production on your standard release schedule. 5. If you have a large fleet, consider staged rollout or canary deployments. 6. Verify the update took effect by checking runtime dependency versions via actuator endpoints or logs.

Detection guidance

Monitor for unusual gRPC traffic patterns targeting your application: look for a spike in malformed or oversized gRPC frames, rapid connection attempts, or exhaustion of file descriptors and memory tied to gRPC listener threads. Inspect application logs for resource-exhaustion warnings, out-of-memory errors, or exceptions in Micrometer gRPC handlers occurring synchronously with traffic spikes. If you deploy with Kubernetes, watch for pod restarts or CrashLoopBackOff events correlated with traffic anomalies. Network-level indicators include sustained high packet rates on gRPC ports (typically 50051, 50052, or application-defined) from single or distributed sources.

Why prioritize this

This vulnerability merits prompt attention because it combines high severity (CVSS 7.5), trivial exploitability, and widespread usage of Micrometer across cloud-native and microservices ecosystems. Unlike vulnerabilities requiring authentication or user interaction, this can be exploited by any attacker with network access. The impact—service unavailability and loss of observability—is direct and damaging in always-on environments. However, it is not yet on the CISA KEV list, suggesting active exploitation in the wild has not been confirmed at scale; still, the attack pattern is straightforward enough that prudent teams should treat this as medium-to-high priority for the next maintenance cycle.

Risk score, explained

CVSS 7.5 (HIGH) reflects the combination of network-level attack feasibility, lack of authentication barriers, and high impact to availability. The scoring reflects that an unauthenticated attacker can cause service denial with minimal effort. The severity does not reach CRITICAL because the scope is limited to the availability of the affected service (not system-wide confidentiality or integrity) and patching is straightforward. Organizations with defense-in-depth practices (network segmentation, rate limiting, DDoS mitigation) can partially offset risk until patches are deployed.

Frequently asked questions