GHSA-8rrq-wcg8-cv5q — obi

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.