OpenTelemetry eBPF Instrumentation: Redis error text is exported in span status messages
Description
Summary
OBI exports raw Redis error text as the span status message. Because Redis error replies can contain attacker-controlled or sensitive values, this behavior can exfiltrate tokens, PII, or other confidential input into telemetry backends and inject untrusted text into downstream analysis systems.
Details
In pkg/ebpf/common/redis_detect_transform.go, getRedisError trims the raw error buffer and stores it directly in request.DBError.Description.
Later, pkg/appolly/app/request/span.go returns that description as the exported status message for Redis spans whenever the span status is non-zero.
There is no opt-in control or sanitization beyond CRLF trimming. As a result, raw Redis error text becomes part of OTLP-exported status metadata by default.
PoC
Local request-layer testing recorded a status message containing ERR invalid password for user bob secret=TOPSECRET, which shows that unfiltered Redis error text reaches the exported status message.
Use a vulnerable build:
git checkout v0.0.0-rc.1+build
make build
Start Redis and OBI:
docker run --rm -p 6379:6379 redis:7
sudo ./bin/obi
Send a command that causes Redis to return an error containing caller-supplied text:
redis-cli -p 6379 'NOTACMD my-secret-token-123'
Capture the exported span or inspect the local telemetry output. On a vulnerable build, the span status message contains the Redis error text, including the supplied command fragment. This demonstrates that raw Redis error text is exported into telemetry by default and that values embedded in that text, including data supplied unintentionally by a caller, can be carried into tracing systems.
Impact
This is an information disclosure and telemetry injection issue. It affects any deployment that traces Redis traffic and exports spans to collectors, logs, or dashboards. Sensitive values, tokens, or PII present in Redis error text can be exfiltrated into telemetry systems, and untrusted text can contaminate downstream analysis.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
OBI (OpenTelemetry eBPF Instrumentation) exports raw Redis error text as span status messages, allowing exfiltration of sensitive data and injection of untrusted text into telemetry backends.
Vulnerability
The vulnerability resides in two files within the OpenTelemetry eBPF Instrumentation (OBI) project. In pkg/ebpf/common/redis_detect_transform.go, the getRedisError function trims only CRLF characters from the raw Redis error buffer and stores the result directly in request.DBError.Description. Subsequently, pkg/appolly/app/request/span.go returns this description as the exported status message for Redis spans whenever the span status is non-zero. There is no sanitization, validation, or opt-in control beyond the minimal trimming. This affects all deployments using OBI builds prior to any official fix, with the PoC using tag v0.0.0-rc.1+build [1], [2], [3].
Exploitation
An attacker can trigger this vulnerability by sending a Redis command that causes the server to return an error message containing attacker-controlled text, such as an unknown command (NOTACMD my-secret-token-123) or an authentication failure that includes a secret. The attacker does not need authentication to the Redis server itself (if accessible), nor does any victim interaction beyond having OBI tracing enabled. The unmodified error text is then automatically included in the OTLP-exported span status message, which is sent to configured telemetry backends [2], [3].
Impact
The impact is twofold: information disclosure and telemetry injection. Sensitive data (tokens, PII, credentials) that appear in Redis error replies—whether from the application, Redis configuration, or attacker-supplied input—are exfiltrated into external telemetry systems (collectors, logs, dashboards). Additionally, untrusted text can contaminate downstream analytics, alerting, and forensic systems, potentially leading to false positives or misattribution. The compromise occurs at the observation layer, not within Redis or the application itself, but the exported data may reach third-party services [2], [3].
Mitigation
As of the available references, no official patched release has been announced for this v0.0.0-rc.1+build version. The project is in development and users should pin to specific semver tags and monitor release notes [1]. Workarounds include disabling Redis tracing in OBI configuration, deploying a custom sanitization middleware in the telemetry pipeline to strip status messages, or restricting network access to Redis from untrusted sources. If the telemetry backend supports filtering, drop spans containing the redis.error attribute. No KEV listing is known at this time [2], [3].
References
AI Insight generated on May 21, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
2< 0.9.0+ 1 more
- (no CPE)range: < 0.9.0
- (no CPE)range: <= v0.0.0-rc.1+build
Patches
0No patches discovered yet.
Vulnerability mechanics
AI mechanics synthesis has not run for this CVE yet.
References
2News mentions
0No linked articles in our index yet.