EUVD-2026-36466Severity by source
AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
AV:N because attacker-controlled remote endpoint is the primary threat model; AC:H because exploitation requires either MITM positioning or endpoint compromise; PR:N since no auth is needed from the attacker side.
Primary rating from Vendor (GitHub_M).
CVSS VectorNVD
CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
Lifecycle Timeline
3DescriptionNVD
OpenTelemetry-cpp is the C++ implementation of OpenTelemetry. Prior to release 1.27.0, the OTLP HTTP exporters (traces/metrics/logs) read the full HTTP response into an in-memory vector of bytes without a size cap. This is exploitable for memory exhaustion when the configured collector endpoint is attacker-controlled (or a network attacker can MITM the exporter connection). This vulnerability is fixed in opentelemetry-cpp release 1.27.0.
AnalysisAI
Memory exhaustion in opentelemetry-cpp OTLP HTTP exporters (traces, metrics, logs) prior to 1.27.0 allows an attacker who controls the configured collector endpoint - or occupies a MITM position on the network path - to crash the instrumented process by returning an arbitrarily large HTTP response body. The curl-based HTTP client read response data into an unbounded in-memory buffer via io-equivalent copy with no size limit, making peak heap allocation entirely attacker-controlled. No public exploit has been identified at time of analysis, and EPSS at 0.02% (6th percentile) indicates low opportunistic exploitation probability, though the targeted threat model (supply-chain-adjacent collector compromise) is realistic in telemetry-heavy environments.
Technical ContextAI
OpenTelemetry-cpp (CPE: cpe:2.3:a:open-telemetry:opentelemetry-cpp:*:*:*:*:*:*:*:*) implements the OTLP HTTP exporter protocol using libcurl. The WriteMemoryCallback, WriteVectorHeaderCallback, and WriteVectorBodyCallback functions in ext/src/http/client/curl/http_operation_curl.cc each called raw insert() on a std::vector<unsigned char> without an upper bound, controlled entirely by the size the remote endpoint chose to send. CWE-789 (Uncontrolled Memory Allocation) precisely characterizes the root cause: attacker-influenced input (the HTTP response body size) directly determines allocation size with no validation gate. An identical pattern was independently confirmed in opentelemetry-go (GHSA-w8rr-5gcm-pp58), affecting otlptrace/otlptracehttp, otlpmetric/otlpmetrichttp, and otlplog/otlploghttp components, indicating this is a systemic design omission across the OpenTelemetry OTLP HTTP client ecosystem. The fix in 1.27.0 imposes a 4MiB cap (kDefaultMaxResponseSize) consistent with the opentelemetry-proto specification recommendation, with overflow-safe arithmetic and three defensive checks in each callback.
RemediationAI
Upgrade opentelemetry-cpp to release 1.27.0, which caps HTTP response body allocation at 4MiB by default (kDefaultMaxResponseSize = 4 * 1024 * 1024) in the curl HTTP client, with overflow-safe arithmetic guarding all three write callbacks. The fix is detailed in PR #4078 at https://github.com/open-telemetry/opentelemetry-cpp/pull/4078 and the security advisory at https://github.com/open-telemetry/opentelemetry-cpp/security/advisories/GHSA-5qhm-4rfp-qqvj. If immediate upgrade is not possible, the primary compensating control is ensuring OTLP HTTP exporters only connect to collector endpoints over mutually authenticated TLS (mTLS), which prevents network-level MITM attacks and limits exploitation to cases where the collector endpoint itself is compromised. Deploying network segmentation to restrict exporter traffic to trusted collector infrastructure reduces the MITM attack surface. Note that the SetMaxResponseSize() API introduced in 1.27.0 also allows operators to tune the cap below 4MiB if needed. For opentelemetry-go deployments, upgrade otlptrace/otlpmetric exporters to 1.43.0 and otlplog to 0.19.0 separately.
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today