CVE-2026-45682: OpenTelemetry eBPF Instrumentation Memory Leak in Java TLS State Tracking

Technical summary

The vulnerability exists in the custom CappedConcurrentHashMap used by OpenTelemetry eBPF Instrumentation to track Java TLS connection state. While the map itself enforces a size cap, its underlying insertion-order queue does not evict entries when keys are deleted from the map. Over time in high-churn environments, queue entries accumulate without bound, consuming heap memory at an accelerating rate. This is rooted in incomplete cleanup logic (CWE-401: Missing Release of Memory After Effective Lifetime; CWE-770: Allocation of Resources Without Limits or Throttling).

Business impact

In production environments, this vulnerability manifests as eventual heap exhaustion and application crashes. For services deployed with OpenTelemetry eBPF Instrumentation monitoring high-traffic Java workloads—particularly those with connection pooling and frequent reconnects—the issue is triggered after hours or days of operation. This translates to unplanned downtime, failed SLOs, and loss of observability data collection during incidents. Organizations running instrumented services without awareness of this flaw risk production outages.

Affected systems

OpenTelemetry eBPF Instrumentation versions prior to 0.9.0 are affected. The issue impacts any long-running Java Virtual Machine instrumented with this agent that handles repeated TLS connection lifecycle events (connection open, close, reopen). Environments with high connection churn—such as microservices communicating over TLS, load-balanced backends, or applications with aggressive connection pooling—face the greatest risk.

Exploitability

This is not an exploitable vulnerability in the traditional sense; there is no remote attack vector or privilege escalation path. Instead, it is a resource exhaustion vulnerability triggered by normal application behavior. An attacker cannot directly trigger the leak, but any environment with high connection turnover will eventually exhaust memory. The CVSS score of 5.1 (Medium) reflects local impact (heap DoS) without requiring special privileges or user interaction, but with elevated complexity due to environmental preconditions (connection churn volume and duration).

Remediation

Upgrade OpenTelemetry eBPF Instrumentation to version 0.9.0 or later. Organizations unable to upgrade immediately should monitor heap memory usage in instrumented JVMs and establish automated restarts or alerts triggered by heap pressure thresholds. Consider temporarily disabling eBPF instrumentation on critical services until patching can be completed, or deploy instrumentation only in non-production or low-churn environments.

Patch guidance

Consult the OpenTelemetry project release notes and vendor advisory for version 0.9.0 to verify availability and any prerequisite compatibility requirements. Test the patched version in a staging environment that replicates your connection churn patterns before rolling to production. Verify heap memory stabilization post-deployment by observing memory metrics over at least one full application cycle (including peak traffic windows).

Detection guidance

Monitor heap memory trend lines in instrumented JVMs. A monotonically increasing heap usage pattern (after accounting for garbage collection cycles) despite stable application load is a strong signal. Enable heap dumps on OutOfMemoryError and inspect the CappedConcurrentHashMap instance to identify queue bloat. Java profilers and heap analysis tools can confirm whether TLS tracking structures are retaining entries. Review OpenTelemetry instrumentation logs for warnings about connection state tracking anomalies.

Why prioritize this

Although the CVSS score is Medium, this vulnerability warrants prompt attention because (1) it affects availability in production long-running services, (2) it is triggered by normal operational patterns (connection recycling), not edge cases, and (3) the fix is straightforward (version upgrade). Organizations with high-throughput Java services should prioritize patching over lower-impact vulnerabilities. However, this does not require emergency response unless instrumented services are already experiencing unexplained heap exhaustion.

Risk score, explained

The CVSS 3.1 score of 5.1 reflects a local scope denial-of-service impact (heap exhaustion) requiring elevated environmental complexity (sustained high connection churn) but no special privileges or user interaction. The attack vector is Local because the instrumentation runs within the JVM process itself. High availability impact is offset by the requirement for specific operational conditions, justifying a Medium severity rating.

Frequently asked questions