CVE-2026-45682
Memory Exhaustion in OpenTelemetry eBPF Instrumentation
Publication date: 2026-06-02
Last updated on: 2026-06-02
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| opentelemetry | ebpf_instrumentation | to 0.9.0 (exc) |
| open_telemetry | opentelemetry_ebpf_instrumentation | to 0.9.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-770 | The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. |
| CWE-401 | The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The provided information does not specify any direct impact of this vulnerability on compliance with common standards and regulations such as GDPR or HIPAA.
Can you explain this vulnerability to me?
CVE-2026-45682 is a memory leak vulnerability in the CappedConcurrentHashMap used by OpenTelemetry's eBPF instrumentation for Java TLS state tracking. The issue arises because the map's insertion-order queue does not remove keys when entries are deleted, causing the queue to grow indefinitely in long-running JVMs with frequent connection churn.
This unbounded growth eventually exhausts heap memory, leading to OutOfMemoryError and impacting the availability of instrumented Java workloads.
The problem was fixed in version 0.9.0 by correcting the remove() method to properly clean up the queue.
How can this vulnerability impact me? :
This vulnerability can cause heap memory exhaustion in Java Virtual Machines running OpenTelemetry eBPF instrumentation with TLS state tracking.
As a result, affected systems may experience OutOfMemoryError, which can lead to application crashes or degraded availability.
This impacts the reliability and uptime of instrumented Java workloads, especially those with long runtimes and frequent TLS connection churn.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability manifests as a memory leak in the CappedConcurrentHashMap used by OpenTelemetry's eBPF instrumentation for Java TLS state tracking. Detection involves monitoring Java Virtual Machine (JVM) heap memory usage for signs of exhaustion or OutOfMemoryError in long-running instrumented JVMs with frequent TLS connection churn.
You can detect the issue by observing JVM logs for OutOfMemoryError events and monitoring heap memory growth over time. Additionally, checking the version of OpenTelemetry eBPF instrumentation in use can help identify vulnerable deployments.
- Use JVM monitoring tools such as jstat, jmap, or VisualVM to track heap usage.
- Check JVM logs for OutOfMemoryError related to heap exhaustion.
- Run commands to verify the OpenTelemetry eBPF instrumentation version, for example, checking your dependency or package manager for the installed version.
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation step is to upgrade the OpenTelemetry eBPF instrumentation to version 0.9.0 or later, where the memory leak issue in CappedConcurrentHashMap has been patched.
Until the upgrade can be applied, consider restarting the instrumented JVMs periodically to clear the heap memory and prevent exhaustion caused by the unbounded queue growth.
Also, review and limit the frequency of TLS connection churn if possible, as repeated short-lived TLS handshakes trigger the vulnerability.