CVE-2026-45681: OpenTelemetry eBPF Instrumentation Memory Leak (MEDIUM)

Technical summary

The vulnerability exists in the per-CPU message-buffer fallback mechanism. OpenTelemetry eBPF Instrumentation allocates a 256-byte backup buffer for scenarios where the primary per-CPU buffer is unavailable, but the original payload size (up to 8KB) is preserved in the message metadata. If a CPU mismatch occurs during the fallback—meaning the buffer was allocated on one CPU but read on another—the code may attempt to read beyond the 256-byte boundary using the larger payload size value. This out-of-bounds read (CWE-125) combined with improper buffer size validation (CWE-130) allows adjacent memory to be read and subsequently transmitted as part of telemetry events. The exposure is confined to the telemetry pipeline; there is no direct remote code execution or denial of service.

Business impact

Organizations using OpenTelemetry eBPF Instrumentation for application performance monitoring face a confidentiality risk. Sensitive data in kernel memory—such as cryptographic material, authentication tokens, configuration secrets, or data from co-resident workloads—could be leaked into telemetry logs and traces. If these telemetry streams are stored, indexed, or shared with third-party monitoring platforms, the exposure scope widens. The leakage is intermittent (triggered by CPU mismatches) and may go undetected without careful log analysis, extending the duration of potential exposure before discovery.

Affected systems

OpenTelemetry eBPF Instrumentation versions prior to 0.9.0 are affected. This includes production deployments of OBI used for instrumenting applications on Linux systems. The vulnerability is most likely to manifest on systems with frequent CPU context switching, workload migration across cores, or those running on oversubscribed cloud infrastructure where CPU pinning is not enforced. Container environments and Kubernetes clusters using OBI are particularly relevant.

Exploitability

The vulnerability requires no authentication and affects the network-facing telemetry export interface. However, exploitation requires favorable conditions: a CPU scheduling mismatch must occur during message-buffer fallback, and the attacker must have access to consume the telemetry stream. The CVSS score of 5.9 (MEDIUM) reflects this conditional nature—high confidentiality impact but high attack complexity and no integrity or availability harm. This is not a trivial exploitation scenario; it is not listed on the CISA Known Exploited Vulnerabilities (KEV) catalog, and no public exploits are known.

Remediation

Upgrade OpenTelemetry eBPF Instrumentation to version 0.9.0 or later. This version corrects the fallback buffer handling to ensure that the payload size cannot exceed the allocated buffer capacity, eliminating the out-of-bounds read condition. Review deployment configurations to ensure that telemetry data collected prior to patching has not been retained or transmitted to untrusted systems; consider log purges if extended retention policies are in place.

Patch guidance

Verify the current version of OpenTelemetry eBPF Instrumentation in your deployment by checking package metadata or version output from the instrumentation binary. The fix is included in version 0.9.0 and all subsequent releases. For containerized deployments, rebuild images with the updated OBI version and perform a rolling deployment. For Kubernetes environments, update any init containers or DaemonSets that include OBI. Test the upgrade in a staging environment to confirm telemetry collection remains functional. No configuration changes are required post-upgrade.

Detection guidance

Monitor logs and telemetry for signs of the vulnerability being triggered: sudden memory content appearing in telemetry events that does not correspond to application data, unusual byte patterns in trace data, or error logs indicating CPU mismatch conditions in eBPF subsystems. If your organization uses SIEM or log aggregation tools, search historical telemetry exports for anomalies such as null bytes, kernel memory signatures, or data that appears unrelated to application state. Correlation with high CPU context-switch events may help identify exposure windows. Enable verbose logging in OpenTelemetry eBPF Instrumentation if available to capture fallback events.

Why prioritize this

Although the CVSS score is MEDIUM, this vulnerability should be prioritized based on data sensitivity. Organizations handling financial, healthcare, or cryptographic workloads should treat this as HIGH priority because kernel memory leakage could expose highly sensitive secrets. For general-purpose monitoring with non-sensitive telemetry, prioritization can be MEDIUM. The lack of public exploits and KEV listing reflects the conditional nature, but the confidentiality exposure is real. Deployment scope and telemetry sharing practices should inform internal risk ranking.

Risk score, explained

CVSS 5.9 is derived from: base score reflects high confidentiality impact (sensitive data leaked to telemetry), no integrity or availability impact, no privileges required, network-accessible telemetry interface, but high attack complexity due to the requirement for CPU scheduling mismatches and telemetry stream access. The score correctly captures the conditional but meaningful risk of memory disclosure without overstating the severity as a remote code execution or system-wide availability threat.

Frequently asked questions