CVE-2026-45679: OpenTelemetry eBPF Information Disclosure

CVE-2026-45679 Overview

CVE-2026-45679 affects OpenTelemetry eBPF Instrumentation (OBI), a project that provides eBPF-based instrumentation aligned with the OpenTelemetry standard. Prior to version 0.9.0, OBI exports raw Redis error reply text directly as the span status message. Redis error replies can contain attacker-controlled or sensitive values, so this behavior can leak tokens, personally identifiable information (PII), or other confidential input into downstream telemetry backends. The flaw also enables injection of untrusted text into log and analysis pipelines that consume span data. The issue is classified under [CWE-117] Improper Output Neutralization for Logs, and was patched in release 0.9.0.

Critical Impact

Sensitive or attacker-controlled Redis error content can be exfiltrated into telemetry backends and injected into downstream log analysis systems.

Affected Products

• OpenTelemetry eBPF Instrumentation (OBI) versions prior to 0.9.0
• Go-based deployments using opentelemetry:ebpf_instrumentation
• Environments instrumenting Redis traffic with OBI

Discovery Timeline

• 2026-06-02 - CVE-2026-45679 published to NVD
• 2026-06-03 - Last updated in NVD database

Technical Details for CVE-2026-45679

Vulnerability Analysis

OBI uses eBPF probes to capture network traffic and translate it into OpenTelemetry spans. When the instrumented application interacts with Redis, OBI inspects RESP protocol responses to determine command outcomes. For error replies, OBI takes the raw error string from the Redis response and copies it verbatim into the span's status message field. No sanitization, truncation, or allow-listing is applied before the value is exported through OTLP to a telemetry backend.

Redis error replies frequently echo back portions of the original command arguments. If a client passes user input, secrets, or PII as a Redis key or value and the command fails, the error text can contain that sensitive content. Once exported, the data is persisted in tracing, logging, and observability stores that may have weaker access controls than the application itself. Operators querying or visualizing spans may also render the untrusted text, enabling log injection against downstream consumers.

Root Cause

The root cause is improper output neutralization for logs [CWE-117]. OBI treats Redis error strings as trusted protocol metadata rather than untrusted, attacker-influenced content. The export path lacks redaction, length limits, and encoding controls before the data crosses into the telemetry pipeline.

Attack Vector

A remote attacker who can influence Redis command arguments, for example through an application endpoint that forwards user input into Redis keys, can trigger error replies that include their chosen payload. The payload then propagates from OBI into OTLP exporters and telemetry backends. The attack requires no authentication against OBI itself and operates over the network through the instrumented application.

No synthetic exploit code is published. Refer to the GitHub Security Advisory GHSA-8rrq-wcg8-cv5q for technical details.

Detection Methods for CVE-2026-45679

Indicators of Compromise

• Span status messages in OTLP backends containing Redis error prefixes such as WRONGTYPE, ERR, or NOAUTH followed by user-supplied strings
• Telemetry records holding token-like, email, or credential patterns inside Redis span attributes
• Log entries with embedded newline or control characters originating from Redis span exports

Detection Strategies

• Query the telemetry data lake for span status.message fields associated with Redis client spans and search for sensitive value patterns
• Inventory all running OBI agents and compare reported versions against 0.9.0 to identify exposed deployments
• Audit application code paths that pass user input into Redis commands without server-side validation

Monitoring Recommendations

• Alert on telemetry ingestion records where Redis span status messages exceed expected length thresholds
• Monitor OBI release metadata across the fleet and flag pods or hosts running pre-0.9.0 builds
• Review observability backend access logs for unusual queries against Redis-tagged spans

How to Mitigate CVE-2026-45679

Immediate Actions Required

• Upgrade OpenTelemetry eBPF Instrumentation to version 0.9.0 or later across all instrumented workloads
• Purge or redact historical span data that may contain leaked Redis error content from telemetry backends
• Rotate any secrets, tokens, or credentials that could have been passed as Redis arguments while vulnerable OBI versions were active

Patch Information

The issue is fixed in OBI 0.9.0. See the GitHub Release v0.9.0 and the GitHub Security Advisory GHSA-8rrq-wcg8-cv5q for full remediation details.

Workarounds

• Disable OBI Redis protocol instrumentation until the upgrade can be deployed
• Apply a span processor at the OpenTelemetry Collector that drops or scrubs the status.message attribute on Redis client spans
• Restrict application code so user-controlled values cannot reach Redis keys or arguments without server-side validation

# Upgrade OBI to the patched release
go install github.com/open-telemetry/opentelemetry-ebpf-instrumentation/cmd/ebpf-instrument@v0.9.0

# Verify installed version
ebpf-instrument --version