CVE-2026-40983

What it actually does

CVE-2026-40983 is a network-reachable denial-of-service vulnerability in Micrometer affecting versions 1.16.0 through 1.16.5 and 1.15.0 through 1.15.11. A specially crafted gRPC request can trigger excessive resource consumption or failure behavior in Micrometer-related processing, causing service degradation or service unavailability. The vulnerability has no confidentiality or integrity impact under the published CVSS vector, but it has high availability impact and requires no authentication or user interaction when the vulnerable gRPC endpoint is reachable.

Why it matters to the business

Applications using affected Micrometer versions with exposed or reachable gRPC handling may become slow, unstable, or unavailable if targeted. This can disrupt customer-facing services, internal platforms, APIs, telemetry pipelines, and dependent business processes. The CVSS score is high at 7.5 because exploitation is remote, low-complexity, and unauthenticated, although current public exploitation signals are low: EPSS is 0.00539, the 30-day EPSS trend is flat, exploit maturity is listed as none, and the vulnerability is not in CISA KEV or known ransomware campaigns.

How an attack unfolds

An attacker first identifies an application or service using an affected Micrometer release and determines whether gRPC traffic can reach the vulnerable code path. They then send specially crafted gRPC requests designed to trigger the denial-of-service behavior. Because the issue is remotely reachable, low complexity, and does not require authentication according to the CVSS vector, exploitation may consist of repeated malformed or edge-case gRPC calls against an exposed endpoint. Successful exploitation results in degraded performance, resource exhaustion, crashes, request handling failures, or loss of availability for the affected service. There is no indication from the provided data that exploitation enables data theft, privilege escalation, or code execution.

How to fix it

Upgrade Micrometer to a fixed version once available from the vendor or project maintainers. At minimum, ensure deployments are not running Micrometer 1.16.0 through 1.16.5 or 1.15.0 through 1.15.11. If exact fixed versions are not yet available in package metadata, monitor official Micrometer release notes and security advisories and update to the first patched release for the active branch. As compensating controls, restrict gRPC endpoint exposure to trusted networks, require authentication where feasible, apply rate limits and request size limits, enforce gRPC deadline/timeouts, deploy ingress filtering or WAF/API gateway controls capable of limiting abnormal gRPC traffic, and ensure service supervisors can restart failed processes safely.

How to confirm the fix worked

Inventory application dependencies using SBOMs, build manifests, dependency scanners, container image scans, and runtime package inspection to confirm whether Micrometer versions 1.16.0 through 1.16.5 or 1.15.0 through 1.15.11 are present. Validate remediation by confirming upgraded dependency versions in source lockfiles, built artifacts, container images, and deployed runtime instances. Perform controlled negative testing in a non-production environment using malformed or boundary-case gRPC requests to verify that the service remains stable, enforces limits, and does not crash or consume excessive resources. Confirm that gRPC endpoints are not unnecessarily internet-exposed and that rate limits, timeouts, and monitoring alerts are active.

Typical attack path

1. Scan for internet-exposed or internally reachable services that accept gRPC traffic.
2. Fingerprint the application stack or dependency metadata to identify use of affected Micrometer versions: 1.16.0 through 1.16.5 or 1.15.0 through 1.15.11.
3. Send specially crafted gRPC requests to the reachable service to exercise the vulnerable Micrometer code path.
4. Repeat or parallelize requests to amplify availability impact.
5. Observe degraded response times, elevated error rates, process instability, resource exhaustion, or service crashes.

How to detect it

To determine whether this was already exploited, review telemetry for gRPC-enabled services using affected Micrometer versions from 2026-06-09 onward. Focus on application logs, gRPC server access logs, API gateway or ingress controller logs, service mesh telemetry, container orchestration events, JVM logs, crash dumps, APM metrics, and infrastructure metrics. Look for sudden bursts of gRPC requests from one or a small set of sources, repeated malformed or rejected gRPC calls, unusual method paths, elevated UNKNOWN, INTERNAL, RESOURCE_EXHAUSTED, CANCELLED, DEADLINE_EXCEEDED, or UNAVAILABLE status codes, abrupt increases in CPU, memory, thread count, garbage collection pressure, request latency, process restarts, pod evictions, health-check failures, and crash loops. Correlate availability incidents with external source IPs, ingress logs, and deployment versions containing Micrometer 1.16.0-1.16.5 or 1.15.0-1.15.11. Because no public exploit indicators or threat actors are provided, detection should emphasize behavioral signs of gRPC-triggered denial of service rather than fixed payload signatures.

• micrometer-core-1.16.0.jar
• micrometer-core-1.16.1.jar
• micrometer-core-1.16.2.jar
• micrometer-core-1.16.3.jar
• micrometer-core-1.16.4.jar
• micrometer-core-1.16.5.jar
• micrometer-core-1.15.0.jar
• micrometer-core-1.15.1.jar
• micrometer-core-1.15.2.jar
• micrometer-core-1.15.3.jar
• micrometer-core-1.15.4.jar
• micrometer-core-1.15.5.jar
• micrometer-core-1.15.6.jar
• micrometer-core-1.15.7.jar
• micrometer-core-1.15.8.jar
• micrometer-core-1.15.9.jar
• micrometer-core-1.15.10.jar
• micrometer-core-1.15.11.jar
• grpc-status: 8
• grpc-status: 13
• grpc-status: 14
• RESOURCE_EXHAUSTED
• DEADLINE_EXCEEDED
• UNAVAILABLE
• CrashLoopBackOff
• OutOfMemoryError
• java.lang.OutOfMemoryError
• java.lang.StackOverflowError

What your security team should do

• Prioritize inventory of services that use Micrometer and accept gRPC traffic, especially internet-facing or cross-trust-boundary services.
• Upgrade affected Micrometer versions as soon as patched releases are available; remove versions 1.16.0 through 1.16.5 and 1.15.0 through 1.15.11 from approved dependency baselines.
• Apply compensating controls immediately for exposed gRPC services, including network restrictions, authentication, rate limiting, request size limits, and timeouts.
• Add monitoring for abnormal gRPC request volume, repeated malformed requests, spikes in 4xx/5xx responses, service restarts, CPU or memory exhaustion, and latency degradation.
• Review incident telemetry from the publication date onward for unexplained availability incidents involving services that use Micrometer and gRPC.
• Track vendor advisories because exact fixed package versions were not provided in the input data.
• Treat this as high-priority for availability-critical systems despite low current EPSS and no KEV listing, because exploitation is remote, unauthenticated, and low complexity.