Deploy autonomous AI agents that reason, exploit, and validate complex vulnerability chains — not another scanner, an agentic system that thinks like a senior pentester.
CVE-2026-45681 is a low severity vulnerability with a CVSS score of 0.0. No known exploits currently, and patches are available.
Very low probability of exploitation
EPSS predicts the probability of exploitation in the next 30 days based on real-world threat data, complementing CVSS severity scores with actual risk assessment.
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.
https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/common/http_buf_size.h#L4-L7
k_kprobes_http2_buf_size is defined as 256 bytes, the size of the fallback buffer.
https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/common/msg_buffer.h#L12-L36
Introduces 8KB per-CPU buffer and 256-byte fallback_buf in msg_buffer_t, creating a size mismatch for fallback use.
https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/generictracer/k_tracer.c#L370-L394
On CPU mismatch, fallback_buf is used but size is still set to m_buf->real_size (up to 8KB) and passed downstream.
https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/generictracer/protocol_http.h#L412-L441
bytes_len (from m_buf->real_size) is used to read payload data from u_buf; if u_buf is the 256B fallback, this can over-read and leak memory into telemetry.
https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/tpinjector/tpinjector.c#L192-L206
real_size is set up to 8192 bytes and stored with cpu_id; fallback_buf only contains 256 bytes.
Local testing with an AddressSanitizer user-space PoC reproduced the same class of size-mismatch over-read as the vulnerable fallback-buffer path. That result is sufficient to ground the advisory in a fresh local reproduction even though the exact end-to-end eBPF path still depends on host BPF capabilities.
To reproduce the validated behavior locally:
Please cite this page when referencing data from Strobes VI. Proper attribution helps support our vulnerability intelligence research.
fallback_buf[256]real_sizereal_sizereal_size bytes from that 256-byte backing store under ASanAn equivalent reproducer is:
// save as /tmp/poc_msgbuf_oob.c
#include <stdint.h>
#include <stdio.h>
#include <string.h>
struct msg_buffer {
unsigned char fallback_buf[256];
uint16_t pos;
uint16_t real_size;
uint32_t cpu_id;
};
int main(void) {
struct msg_buffer m = {0};
unsigned char sink[8192];
memset(m.fallback_buf, 'A', sizeof(m.fallback_buf));
m.real_size = 4096;
memcpy(sink, m.fallback_buf, m.real_size);
printf("copied %u bytes from a 256-byte fallback buffer\n", m.real_size);
return 0;
}
Compile and run with ASan:
cc -fsanitize=address -O1 -g -o /tmp/poc_msgbuf_oob /tmp/poc_msgbuf_oob.c
ASAN_OPTIONS=abort_on_error=1 /tmp/poc_msgbuf_oob
Expected result:
AddressSanitizer: heap-buffer-overflow or stack-buffer-overflow
That user-space PoC matches the size-mismatch condition in the vulnerable code path, even though the exact end-to-end eBPF runtime path still requires host BPF attach/load capability.
This is a confidentiality issue in the HTTP tracing path. The vulnerable read occurs in OBI's local fallback-buffer handling when context propagation is enabled, the tpinjector sock_msg path is active, HTTP large-buffer capture is configured with a non-zero size, and a CPU mismatch occurs between producer and consumer contexts. Under those conditions, OBI can over-read from the fallback buffer and export unrelated memory through telemetry.