OpenTelemetry OBI CVE-2026-45679

OBI must be deployed and actively tracing Redis traffic via its eBPF instrumentation - this is the default operating mode for any Redis-connected application instrumented with OBI, requiring no special configuration flag to be enabled. Redis errors must contain sensitive or attacker-influenced text; this occurs naturally in two scenarios: (1) authentication errors where Redis echoes back user context (e.g., ERR invalid password for user bob secret=TOPSECRET), and (2) invalid command errors where Redis reflects the unrecognized command name back in the error reply, allowing a caller who can send any Redis command to embed arbitrary text in the error. No authentication to OBI, the Redis instance, or the telemetry backend is required for the exfiltration path to activate - the CVSS vector PR:N confirms unauthenticated network access is sufficient. Exploitation is bounded by two factors: the attacker must have sufficient network access to trigger Redis errors (directly or by influencing application requests), and the sensitive data must actually appear in Redis error text rather than only in successful command payloads. Deployments where Redis errors never contain sensitive values and where telemetry backends are strictly access-controlled face reduced practical risk.

The CVSS 6.5 score (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N) reflects network-accessible, zero-authentication exploitation with low complexity. The C:L component captures the indirect confidentiality impact: sensitive values are not directly returned to the attacker from the Redis server, but are exfiltrated into telemetry pipelines that operators or downstream consumers may access - the blast radius depends entirely on who can read the OTLP backend. The I:L component captures the telemetry injection risk: untrusted text inserted into span status messages can corrupt SIEM queries, alert logic, or dashboard visualizations that rely on structured telemetry. No EPSS score was provided in the available data, so exploitation probability cannot be quantitatively compared. The vulnerability is not listed in CISA KEV, indicating no confirmed widespread active exploitation at time of analysis. However, the existence of a detailed PoC in the public advisory (with exact reproduction steps) meaningfully lowers the barrier to exploitation. Real-world priority is highest in environments that: (1) use OBI to trace Redis traffic, (2) store or forward OTLP spans containing sensitive Redis command context, and (3) expose telemetry backends beyond a tightly controlled trust boundary. In air-gapped or single-tenant observability stacks with restricted telemetry access, practical impact is lower despite the medium CVSS.

A publicly available PoC is included in the GHSA advisory. An unauthenticated caller with network access to a Redis instance monitored by OBI sends a command containing a sensitive value (e.g., redis-cli -p 6379 'NOTACMD my-secret-token-123'); Redis returns an error echoing the invalid command fragment. OBI's eBPF hook captures the RESP error reply, getRedisError stores the raw text without sanitization, and the value is emitted as the OTLP span status message in the next export cycle. The sensitive token then appears in any connected telemetry backend - Jaeger, Zipkin, Grafana Tempo, or a centralized SIEM - accessible to operators or exposed via a misconfigured observability endpoint, without the attacker needing any direct access to those systems.