Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Lifecycle Timeline
2DescriptionGitHub Advisory
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 buildStart Redis and OBI:
docker run --rm -p 6379:6379 redis:7
sudo ./bin/obiSend 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.
AnalysisAI
OpenTelemetry eBPF Instrumentation (OBI) versions prior to 0.9.0 forwards raw Redis error replies verbatim into OTLP span status messages, enabling both information disclosure and telemetry injection against any deployment tracing Redis traffic. The getRedisError function in pkg/ebpf/common/redis_detect_transform.go applies only CRLF trimming before storing error text directly into request.DBError.Description, which span.go then exports as the span status message for every non-zero-status Redis span. A publicly available proof-of-concept demonstrates that caller-supplied values embedded in Redis error replies - including authentication credentials, tokens, and PII - are automatically propagated into OTLP collectors, dashboards, and log aggregators without requiring any special attacker position beyond the ability to trigger Redis errors. No public exploit identified at time of analysis beyond the included PoC; not in CISA KEV.
Technical ContextAI
OBI (go.opentelemetry.io/obi) is an eBPF-based auto-instrumentation agent for OpenTelemetry that intercepts application traffic at the kernel level - including the Redis Serialization Protocol (RESP) - without requiring code changes. When OBI observes a Redis error reply, the function getRedisError in pkg/ebpf/common/redis_detect_transform.go (lines 60-74) trims the raw kernel buffer and assigns it to request.DBError.Description. The function in pkg/app/request/span.go (lines 347-352) then unconditionally uses that description as the exported OTLP span status message for any Redis span whose status is non-zero. The root cause maps to CWE-117 (Improper Output Neutralization for Logs): the software writes externally influenced data - specifically Redis error text, which can echo back caller-supplied command fragments or reveal server-side authentication details - to an output channel (telemetry) without sanitization. Redis itself often reflects portions of invalid commands in its error replies (e.g., ERR unknown command 'NOTACMD', with args beginning with: my-secret-token-123), meaning attacker-controlled input can reliably flow into OBI-captured spans. The affected package is identified by CPE pkg:go/go.opentelemetry.io_obi, all versions below 0.9.0.
RemediationAI
Upgrade go.opentelemetry.io/obi to version 0.9.0 or later, which is the vendor-confirmed fixed release per the upstream advisory at https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/security/advisories/GHSA-8rrq-wcg8-cv5q. For deployments that cannot upgrade immediately, three compensating controls are available with noted trade-offs: First, disable Redis tracing in OBI's instrumentation configuration to prevent error capture entirely - this eliminates the exposure but removes Redis observability coverage. Second, deploy an OpenTelemetry Collector pipeline with the redaction processor configured to scrub or hash span status message fields before forwarding to storage backends - this preserves span structure while preventing sensitive text from reaching long-term storage, but requires collector infrastructure and introduces a processing step that may miss novel patterns. Third, restrict access to OTLP receivers, tracing backends, and dashboards to trusted operators only, reducing the population that can observe exfiltrated data - this is a containment measure, not a remediation, and does not prevent the data from entering the pipeline. Apply the upstream patch as soon as operationally feasible; the compensating controls above should be treated as temporary.
LiteSpeed User-End cPanel Plugin before 2.4.5 allows privilege escalation (possibly to root), as exploited in the wild i
UAF in Redis 8.2.1 via crafted Lua scripts by authenticated users. EPSS 12.4%. Patch available.
It was discovered, that redis, a persistent key-value database, due to a packaging issue, is prone to a (Debian-specific
Memory Corruption was discovered in the cmsgpack library in the Lua subsystem in Redis before 3.2.12, 4.x before 4.0.10,
Redis is an open source, in-memory database that persists on disk. Versions 8.2.1 and below allow an authenticated user
Redis before 2.8.21 and 3.x before 3.0.2 allows remote attackers to execute arbitrary Lua bytecode via the eval command.
A buffer overflow in Redis 3.2.x prior to 3.2.4 causes arbitrary code execution when a crafted command is sent. Rated cr
Code injection in OneUptime monitoring via custom JS monitor using vm module. PoC and patch available.
In applications using jfinal 4.9.08 and below, there is a deserialization vulnerability when using redis,may be vulnerab
An issue was found in Apache Airflow versions 1.10.10 and below. Rated critical severity (CVSS 9.8), this vulnerability
An Integer Overflow issue was discovered in the struct library in the Lua subsystem in Redis before 3.2.12, 4.x before 4
goanother Another Redis Desktop Manager =<1.6.1 is vulnerable to Cross Site Scripting (XSS) via src/components/Setting.v
Same weakness CWE-117 – Improper Output Neutralization for Logs
View allSame technique Information Disclosure
View allVendor StatusVendor
SUSE
Severity: Medium| Product | Status |
|---|---|
| SUSE Linux Enterprise Desktop 15 SP7 | Fixed |
| SUSE Linux Enterprise High Performance Computing 15 SP7 | Fixed |
| SUSE Linux Enterprise Module for Basesystem 15 SP7 | Fixed |
| SUSE Linux Enterprise Server 15 SP7 | Fixed |
| SUSE Linux Enterprise Server 16.0 | Fixed |
| SUSE Linux Enterprise Server 16.1 | Fixed |
| SUSE Linux Enterprise Server for SAP Applications 15 SP7 | Fixed |
| SUSE Linux Enterprise Server for SAP applications 16.0 | Fixed |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Fixed |
| openSUSE Leap 16.0 | Fixed |
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-33953
GHSA-8rrq-wcg8-cv5q