CVE-2026-45679: OpenTelemetry eBPF Instrumentation Data Exfiltration via Redis Error Messages

Technical summary

CVE-2026-45679 is a data exfiltration flaw in OpenTelemetry eBPF Instrumentation (OBI) affecting versions prior to 0.9.0. The vulnerability stems from improper handling of Redis protocol error replies. When OBI instruments Redis client calls, it captures the span status message by directly exporting the raw error text returned by Redis. Redis error replies are unstructured text and can include attacker-controlled content or sensitive values from the client request context. Because the instrumentation layer does not sanitize or filter these messages before exporting them to telemetry backends, confidential data—such as authentication credentials, API keys, database connection strings, or customer PII—can be captured and persisted in observability platforms (e.g., Jaeger, Datadog, New Relic, Prometheus). The vulnerability maps to CWE-117 (Improper Output Neutralization for Logs) and CWE-532 (Insertion of Sensitive Information into Log File), reflecting both the log injection and confidentiality risks.

Business impact

This vulnerability creates a secondary attack surface through your observability infrastructure. Organizations using OBI to instrument Redis calls risk leaking high-value secrets into telemetry backends that may be accessed by a broader set of personnel, archived long-term, or integrated with third-party SaaS providers. Compromised credentials captured in telemetry could enable lateral movement, privilege escalation, or unauthorized access to backend systems. Regulatory exposure is also relevant: sensitive customer data or payment information appearing in logs may trigger GDPR, HIPAA, PCI-DSS, or similar compliance reporting obligations. The risk is compounded if telemetry data is retained across multiple environments (dev, staging, production) or synchronized to external monitoring vendors with varying security postures.

Affected systems

OpenTelemetry eBPF Instrumentation versions prior to 0.9.0 are affected. Any application using OBI to instrument Redis client libraries is at risk. Organizations running containerized or Kubernetes workloads that employ OBI for observability are particularly exposed, as eBPF instrumentation often operates at the host or container level with broad visibility into network traffic. The vulnerability affects all platforms and deployment models where OBI version < 0.9.0 is active.

Exploitability

Exploitability requires no special privileges or user interaction. The vulnerability is triggered passively during normal Redis error responses—any condition that generates a Redis error (invalid credentials, keyspace errors, protocol violations, or malformed commands) can cause sensitive data to leak if that data appears in the error message. An attacker does not need network access to the telemetry backend; they only need to cause a Redis error that contains sensitive content, which the instrumentation will automatically export. This makes the attack surface broad and the exploitability straightforward, though practical impact depends on whether sensitive data naturally appears in Redis error contexts in the target environment.

Remediation

Upgrade OpenTelemetry eBPF Instrumentation to version 0.9.0 or later. The patch removes the raw export behavior and implements sanitization of Redis error text before inclusion in span status messages. Organizations should also review telemetry retention policies and access controls to minimize exposure of any logs captured prior to patching. Consider scanning existing telemetry archives for evidence of leaked credentials or PII using keyword-based detection or regex patterns matching common secret formats.

Patch guidance

Patch by upgrading OBI to version 0.9.0 or later. Verify the upgrade through your package manager or container image repository. Test in non-production environments first to confirm compatibility with your existing observability stack and instrumentation configuration. Once patched, the instrumentation will no longer export raw Redis error text, instead substituting a sanitized span status message. No configuration changes are required; the fix is transparent upon upgrade.

Detection guidance

Search telemetry backend query logs and archives for patterns indicative of exposed secrets: API key formats (e.g., 'sk_', 'pk_', 'Bearer '), database credentials (e.g., 'user=', 'password='), or PII patterns (SSN, credit card BINs, email addresses). Monitor OBI logs and instrumentation metrics for high error rates on Redis calls, which may correlate with attempted credential exfiltration. Review access logs on telemetry backends (Jaeger UI, Datadog, etc.) for unusual queries or exports of sensitive data. Correlate timeline of this advisory with any security incidents involving credential compromise on systems running instrumented Redis clients.

Why prioritize this

Although the CVSS score of 6.5 (MEDIUM) reflects the absence of direct system compromise or availability impact, the vulnerability warrants prioritization due to its silent nature and high business risk. Data exfiltration into observability systems is often undetected for extended periods. Organizations handling regulated data (payment, healthcare, PII) should prioritize patching before the modified date (2026-06-17) to reduce the window of potential exposure. The lack of KEV listing does not diminish urgency; this is a confidentiality breach with long-tail compliance and reputational costs.

Risk score, explained

CVSS 6.5 is assigned under version 3.1. The score reflects: Network-accessible attack vector (AV:N), low attack complexity (AC:L), no authentication required (PR:N), no user interaction (UI:N), and impact limited to confidentiality and integrity within the telemetry subsystem (C:L, I:L, A:N). The scope is unchanged (S:U) because the attack does not cross security boundaries in the traditional sense; the data exfiltration occurs within the application's own observability infrastructure. However, this score does not fully capture the business risk of credential or PII exposure; organizations should weight the practical sensitivity of their telemetry content when determining internal risk appetite.

Frequently asked questions