CVE-2026-44967: OpenTelemetry-cpp HTTP Memory Exhaustion Denial of Service

Technical summary

CVE-2026-44967 is an uncontrolled resource consumption vulnerability (CWE-789) in the OTLP HTTP exporter implementations within OpenTelemetry-cpp prior to 1.27.0. The exporters for traces, metrics, and logs all exhibit the same pattern: they read incoming HTTP response bodies directly into a std::vector without enforcing a maximum size limit. An attacker positioned to control the remote endpoint or perform network-layer interception (MITM) can respond with HTTP bodies of arbitrary size, forcing unbounded memory allocation on the client side. The CVSS 3.1 score of 5.3 (MEDIUM, AV:A/AC:H) reflects that exploitation requires network proximity and is somewhat constrained by transport-layer factors, but impact on availability is classified as High.

Business impact

For any organization deploying OpenTelemetry-cpp to instrument containerized or cloud-native applications, this vulnerability introduces an availability risk. If the configured OTLP collector endpoint is on a shared or untrusted network, or if DNS/routing controls are weak, a malicious endpoint can trigger memory exhaustion in the instrumented application itself. In production Kubernetes clusters or multi-tenant environments, this could lead to Pod eviction, cascading failures, and degraded observability—ironically, during a time when monitoring is most critical. The severity is contained by the requirement for network control, but the blast radius can be significant if the collector endpoint is compromised or misconfigured.

Affected systems

The vulnerability affects OpenTelemetry-cpp versions prior to 1.27.0. All applications using the OTLP HTTP exporter for traces, metrics, or logs are at risk. This includes both direct library users and applications that depend on OpenTelemetry-cpp through transitive dependencies. No other OpenTelemetry language implementations (Python, Java, Go, etc.) are affected by this specific flaw. The vulnerability does not affect OpenTelemetry Protocol (OTLP) itself—only the C++ client-side handling of HTTP responses.

Exploitability

Exploitation requires the attacker to have control over the network path between the instrumented application and its configured collector endpoint, or to operate the collector endpoint itself. In on-premises deployments with tight network segmentation, the risk is lower. In cloud environments where the collector endpoint is remote and routing is less predictable, or in development/test environments where endpoint configuration may be looser, the attack surface is wider. The vulnerability does not require user interaction or special privileges; it is triggered automatically when the application initializes the exporter and connects to a malicious or compromised endpoint. Proof-of-concept is straightforward: any HTTP server responding with a large body will trigger the memory exhaustion.

Remediation

Upgrade to OpenTelemetry-cpp release 1.27.0 or later. Verify against the official project repository and release notes to confirm the patch addresses the OTLP HTTP exporter buffer handling. In the interim, restrict network egress and ingress policies to ensure the OTLP collector endpoint is reachable only from trusted sources, and audit endpoint configuration across all instrumented applications to confirm it points to legitimate, controlled infrastructure. Where upgrading is delayed, consider disabling the HTTP exporter temporarily and switching to alternative transport (e.g., gRPC) if available and patched.

Patch guidance

Review your OpenTelemetry-cpp dependency version across all codebases, including transitive dependencies declared in build manifests (vcpkg, Conan, CMake, etc.). Create a test environment that replicates your production endpoint configuration. Deploy the patched version (1.27.0+) and verify that exporter initialization and telemetry export function as expected—pay special attention to error handling and retry behavior, as the patch may alter how oversized responses are handled. In CI/CD pipelines, enforce a minimum version constraint for the OpenTelemetry-cpp dependency to prevent regression. Communicate the patch timeline to development teams to prioritize compilation and testing.

Detection guidance

Monitor for unusual memory growth or Out-of-Memory (OOM) events in processes running OpenTelemetry-cpp exporters, particularly if the growth correlates with network activity toward the configured OTLP collector. Check application logs and kernel logs (dmesg, journalctl) for memory allocation failures or process termination due to resource exhaustion. Network-level detection is more challenging but can include monitoring for large HTTP responses from the collector endpoint (e.g., responses > 1 GB in Content-Length header) that should not occur in normal telemetry export. If available, instrument the OpenTelemetry library itself to log response sizes before buffering.

Why prioritize this

This vulnerability should be prioritized as a medium-risk item for patching within the next 30–60 days, particularly for production deployments in multi-tenant or shared-network environments. The requirement for network control to exploit it lowers urgency compared to pre-auth remote code execution flaws, but the availability impact and the difficulty of detecting attacks in real time warrant proactive remediation. Applications in air-gapped or tightly segmented networks can defer patching with lower risk, but they should still be tracked for eventual update.

Risk score, explained

The CVSS 3.1 score of 5.3 (MEDIUM) balances low attack vector (network-adjacent, requiring MITM or endpoint control) and high complexity against a high availability impact. The score does not reflect loss of confidentiality or integrity, only denial of service. For organizations where telemetry is mission-critical or where the collector endpoint cannot be strictly controlled, the business risk may exceed the numeric CVSS rating. Conversely, for applications in secure, segmented networks with strong endpoint validation, practical risk is lower.

Frequently asked questions