Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
11 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A remotely reachable integer overflow in OBI's memcached text protocol parser can crash the OBI process and cause denial of service. When parsing memcached storage commands such as set, add, replace, append, prepend, or cas, OBI accepts extremely large <bytes values and adds the payload delimiter length without checking for overflow. A crafted request with <bytes set to math.MaxInt or math.MaxInt-1 causes the computed payload length to wrap negative and triggers a runtime panic in LargeBufferReader.Peek. Details The issue is in the memcached request parser at pkg/ebpf/common/memcacheddetecttransform.go. memcachedCommandBytesField parses the storage command <bytes field with strconv.Atoi and only rejects negative values: Because there is no upper bound check, values up to math.MaxInt are accepted. memcachedConsumeStoragePayload then computes the payload length by adding the trailing \r\n delimiter length: If bytesField is math.MaxInt or math.MaxInt-1, this addition overflows…
Recommended action: Upgrade to 0.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Malformed MongoDB wire messages can trigger uncaught panics in the MongoDB TCP parser, allowing a remote unauthenticated attacker to crash the telemetry agent and cause a denial of service. The parser operates on raw attacker-controlled network payloads before the input is fully validated, so a single crafted message can terminate telemetry collection for the affected process or node. Details MongoDB parsing support was introduced by commit 2070f568a (Add Initial support for mongodb), so the explicit released version minimum affected is v0.1.0. There are two related panic conditions in released go.opentelemetry.io/obi versions: - In v0.1.0 through v0.3.0, parseOpMessage reads OPMSG flag bits from buf[msgHeaderSize:msgHeaderSize+int32Size] without first ensuring the buffer is at least msgHeaderSize + int32Size bytes long. A truncated OPMSG packet can therefore trigger a slice-bounds panic before the parser returns an error. - In v0.1.0 through v0.3.0, parseSections consumes…
Recommended action: Upgrade to 0.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OBI's log enricher mishandles writev buffers by reading only the first iovec entry but using the total ioviter.count as the copy length. When log injection is enabled, a crafted multi-segment writev call can make OBI read and overwrite memory beyond the first segment. Details In bpf/logenricher/logenricher.c#L50, filliov resolves only one struct iovec, specifically iovctx.iov[0] for ITERIOVEC. The returned iov therefore describes only the first write segment. However, write later uses const sizet count = BPFCOREREAD(from, count);, which is the total byte count across all segments in the iterator. That total is stored in e-len and used in bpfprobereaduser(e-log, e-len, iov.iovbase) and bpfprobewriteuser(iov.iovbase, zero, towrite). If count exceeds iov.iovlen, OBI reads and then zeroes memory past the end of the first segment. In practice, this can corrupt adjacent application buffers, leak memory into log events, and in some layouts destabilize the instrumented process. PoC…
Recommended action: Upgrade to 0.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The custom CappedConcurrentHashMap introduced for Java TLS state tracking never removes keys from its insertion-order queue when entries are deleted. In long-running instrumented JVMs, repeated connection churn can therefore grow the queue without bound and exhaust heap memory. Details The vulnerable implementation is in pkg/internal/java/agent/src/main/java/io/opentelemetry/obi/java/instrumentations/util/CappedConcurrentHashMap.java#L11. New keys are appended to a ConcurrentLinkedQueue, and eviction only runs inside put() when map.size() capacity. The remove() method removes the key from the ConcurrentHashMap but leaves the key in the queue. Because evictIfNeeded() only checks map.size() capacity, the queue can grow forever in workloads that insert and remove keys while keeping the live map below the cap. This pattern is reachable from pkg/internal/java/agent/src/main/java/io/opentelemetry/obi/java/instrumentations/data/SSLStorage.java#L66, where cleanupConnectionBufMapping…
Recommended action: Upgrade to 0.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Java TLS ioctl probe reads user-controlled ioctl pointers with bpfproberead instead of bpfprobereaduser. An instrumented local process can therefore point OBI at kernel memory and cause that memory to be copied into telemetry. Details The vulnerable path is in bpf/generictracer/javatls.c. The kprobe hooks dovfsioctl, filters on fd == 0 and the Java TLS magic command, and then treats the third ioctl argument as a structured buffer. It reads fields from that pointer using bpfproberead, including: - the operation byte from arg - connection metadata from arg + 1 - the payload length from arg + 1 + sizeof(connectioninfot) If len 0, it computes buf = arg + 1 + sizeof(connectioninfot) + sizeof(u32) and passes that pointer into handlebufwithconnection. The next stage, bpf/generictracer/ktracerdefs.h, uses bpfproberead(args-smallbuf, MINHTTP2SIZE, (void )args-ubuf); on the supplied pointer and tail-calls deeper protocol logic. The HTTP protocol path then reads from ubuf and emits…
Recommended action: Upgrade to 0.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The per-CPU message-buffer fallback path uses a 256-byte backup buffer but preserves the original payload size, which can be up to 8KB. If a CPU mismatch occurs, OBI can read beyond the fallback buffer and leak adjacent memory into telemetry. Details https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/common/httpbufsize.h#L4-L7 kkprobeshttp2bufsize is defined as 256 bytes, the size of the fallback buffer. https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/common/msgbuffer.h#L12-L36 Introduces 8KB per-CPU buffer and 256-byte fallbackbuf in msgbuffert, creating a size mismatch for fallback use. https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/generictracer/ktracer.c#L370-L394 On CPU mismatch, fallbackbuf is used but size is still set to mbuf-realsize (up to 8KB) and passed…
Recommended action: Upgrade to 0.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OBI replays BPF probe hits into histogram observations by looping once per recorded run count. On busy systems, the run-count delta can become very large, causing the metrics exporter to spend excessive CPU time in a tight loop every collection interval. Details The vulnerable loop is in pkg/export/prom/prombpf.go. During each metrics tick, OBI iterates through probeMetrics and then executes for range metric.count, invoking BpfProbeLatency(...) for each individual recorded hit. The count comes from calculateStats() in the same file, where deltaCount := bp.runCount - bp.prevRunCount is calculated and returned without any cap before the per-hit replay loop. If probe activity spikes between scrape intervals, deltaCount can be very large. The exporter then spends CPU time proportional to the number of probe hits rather than the number of metric series. PoC Local testing with a small reproducer confirmed the replay-loop behavior and showed CPU scaling with the recorded hit count…
Recommended action: Upgrade to 0.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Postgres protocol parser assumes BIND message payloads contain a valid NUL-terminated portal name. A crafted empty or unterminated payload can make OBI slice beyond the end of the captured buffer and panic. Details The vulnerable logic is in pkg/ebpf/common/sqldetectpostgres.go. In the BIND case, OBI converts the full payload to a string with unix.ByteSliceToString(msg.data), computes portalLen := len(portal) + 1, and then slices msg.data[portalLen:] to derive the statement name. There is no check that msg.data actually contains a NUL terminator or even enough bytes for portalLen. With an empty payload or a truncated message, portalLen can exceed the slice length and trigger a runtime panic. PoC Local testing with a minimal reproducer showed the expected slice bounds out of range crash for an empty BIND payload. Use a vulnerable build: Start a local Postgres instance and OBI: Send a malformed BIND frame with an empty payload: Run it: On a vulnerable build, the Postgres…
Recommended action: Upgrade to 0.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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/redisdetecttransform.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: Start Redis…
Recommended action: Upgrade to 0.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OBI's replacement ELF parser trusts section offsets, counts, and string offsets from the executable file. A crafted local ELF can make OBI dereference invalid section pointers or slice past string tables, causing the agent to panic while determining the process language. Details matchExeSymbols iterates over sections and uses offsets/symbol names from the unvalidated fastelf context; nil section pointers or out-of-range offsets can trigger panics during dereference/slicing. https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/cec36c1b872beba9d17956bfde75dee3249a1516/pkg/internal/exec/proclanglinux.go#L133-L165 GetCStringUnsafe and ReadStruct perform unsafe slicing and pointer conversion without guarding against out-of-range or negative offsets derived from ELF data, enabling panics on malformed input. https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/cec36c1b872beba9d17956bfde75dee3249a1516/pkg/internal/fastelf/fastelf.go#L201-L213…
Recommended action: Upgrade to 0.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw in the Java agent injection path allows a local attacker controlling a Java workload to overwrite arbitrary host files when Java injection is enabled and OBI is running with elevated privileges. The injector trusted TMPDIR from the target process and used unsafe file creation semantics, enabling both filesystem boundary escape and symlink-based file clobbering. Remediation Upgrade to https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/releases/tag/v0.8.0. Details The issue is in the Java agent staging logic in pkg/internal/java/javainject.go. The injector reads TMPDIR from the target process environment in findTempDir(...) and validates it with dirOK(...). In the vulnerable implementation, dirOK(...) used filepath.Join(root, dir), where root is /proc/<pid/root. If dir is an absolute path, filepath.Join discards root, so values such as /etc or /proc/1/root/etc are resolved on the host instead of within the target process root. That validated value is…
Recommended action: Upgrade to 0.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.