CVE-2026-39882

What it actually does

OpenTelemetry-Go versions prior to 1.43.0 contain an unbounded memory allocation flaw in the OTLP HTTP exporters for traces, metrics, and logs. When an exporter receives an HTTP response from its configured collector endpoint, it reads the entire response body into an in-memory bytes.Buffer without enforcing a maximum size. If the collector endpoint is controlled by an attacker, or if an attacker can intercept or modify exporter-to-collector traffic, the attacker can return an extremely large or never-ending response body and force the instrumented Go process to consume excessive memory. The primary impact is denial of service through process slowdown, out-of-memory termination, container restart loops, or host-level memory pressure. The issue does not directly provide code execution, data theft, or privilege escalation.

Why it matters to the business

Applications using vulnerable OpenTelemetry-Go OTLP HTTP exporters can be made unstable or unavailable if telemetry traffic is directed to a malicious collector or intercepted in transit. This can disrupt customer-facing services, internal platforms, batch jobs, and observability pipelines because the flaw affects the application process embedding the exporter, not only a separate monitoring component. The risk is highest where collector endpoints are externally configurable, dynamically discovered, supplied through environment variables or deployment configuration, or reached over networks where TLS validation can be bypassed or intercepted. EPSS is currently very low and there is no known KEV listing or mature public exploitation, but the fix should still be prioritized for Go services that send telemetry over OTLP/HTTP, especially in multi-tenant, internet-connected, or less trusted network environments.

How an attack unfolds

An attacker first needs influence over the OTLP HTTP exporter response path. This can occur if they control the configured collector endpoint, compromise or impersonate a collector, poison configuration or service discovery that determines the collector URL, or perform a man-in-the-middle attack where exporter TLS protections are absent, disabled, or improperly validated. Once the instrumented Go application sends telemetry to the attacker-controlled endpoint, the attacker responds with an HTTP body that is very large or streams data continuously. Vulnerable OpenTelemetry-Go exporter code reads the complete response body into memory without a size cap. As memory usage grows, the application may experience garbage-collection pressure, latency spikes, failed allocations, out-of-memory kills, container restarts, or process termination. Repeating the interaction can keep the service degraded or unavailable.

How to fix it

Upgrade OpenTelemetry-Go to version 1.43.0 or later wherever OTLP HTTP exporters are used. Review Go module dependencies for go.opentelemetry.io/otel and related OTLP exporter modules, then rebuild and redeploy affected applications. If immediate upgrade is not possible, reduce exposure by ensuring OTLP collector endpoints are trusted, enforcing HTTPS with valid certificate verification, preventing insecure skip-verify configurations, restricting egress so applications can send telemetry only to approved collectors, and preventing untrusted users from changing telemetry endpoint configuration. Prefer local or internal collectors over externally reachable endpoints, and apply memory limits and restart policies to contain impact, recognizing these are compensating controls rather than a fix.

How to confirm the fix worked

Confirm that deployed binaries are built with OpenTelemetry-Go version 1.43.0 or later. Use dependency inspection such as `go list -m all | grep go.opentelemetry.io` or SBOM/software composition analysis to identify vulnerable versions in source and built artifacts. Verify that OTLP HTTP exporters are not configured to send data to untrusted endpoints and that TLS certificate verification is enabled. In staging, confirm exporter behavior by testing with an oversized collector response and verifying the application does not show unbounded memory growth. Validate production exposure by reviewing environment variables, configuration files, Helm charts, container manifests, and service discovery settings for OTLP endpoint values such as OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_EXPORTER_OTLP_TRACES_ENDPOINT, OTEL_EXPORTER_OTLP_METRICS_ENDPOINT, and OTEL_EXPORTER_OTLP_LOGS_ENDPOINT.

Typical attack path

1. Identify a Go application using OpenTelemetry-Go OTLP HTTP exporters for traces, metrics, or logs before version 1.43.0.
2. Gain control over, impersonate, or intercept the configured OTLP/HTTP collector endpoint.
3. Wait for or trigger the application to export telemetry to the malicious endpoint.
4. Return an HTTP response with an excessively large or continuously streaming body.
5. Cause the exporter to buffer the response body in memory without a size limit.
6. Drive memory exhaustion, process termination, container restarts, or service unavailability.

How to detect it

Look for evidence that vulnerable Go applications communicated with unexpected or untrusted OTLP/HTTP collector endpoints shortly before memory exhaustion or crashes. Relevant log sources include application logs, container runtime events, Kubernetes events, system OOM logs, endpoint detection telemetry, egress firewall or proxy logs, service mesh logs, DNS logs, and collector or reverse-proxy access logs. Investigate sudden changes to OTLP endpoint configuration, unusual DNS resolutions for collector hostnames, HTTP responses from collector endpoints with very large response sizes, long-lived response streams, repeated exporter errors, and process restarts correlated with telemetry export attempts. On Kubernetes, review pod events for OOMKilled or CrashLoopBackOff states affecting Go services that use OpenTelemetry. On Linux hosts, inspect kernel logs for out-of-memory killer messages naming the application process. Because this vulnerability does not require a distinctive payload and the malicious response body can be arbitrary, detection should focus on behavior: abnormal memory growth, oversized HTTP responses from telemetry collectors, unexpected collector destinations, and crashes following OTLP export activity.

• OTEL_EXPORTER_OTLP_ENDPOINT=
• OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=
• OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=
• OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=
• go.opentelemetry.io/otel
• go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp
• go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp
• go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp
• OOMKilled
• CrashLoopBackOff
• Out of memory: Killed process
• signal: killed
• context deadline exceeded
• failed to upload traces
• failed to upload metrics
• failed to upload logs
• OTLP
• /v1/traces
• /v1/metrics
• /v1/logs

What your security team should do

• Inventory Go applications and services using OpenTelemetry-Go OTLP HTTP exporters for traces, metrics, or logs.
• Prioritize upgrade to OpenTelemetry-Go 1.43.0 or later for services where telemetry collector endpoints are externally configurable, cross trust boundaries, or are reached over untrusted networks.
• Search source repositories, SBOMs, and container images for go.opentelemetry.io/otel dependencies below 1.43.0.
• Restrict telemetry egress to approved collector hosts and block arbitrary outbound OTLP/HTTP destinations.
• Audit deployment configuration for attacker-controllable OTLP endpoint values and insecure TLS settings.
• Monitor affected services for memory spikes, out-of-memory kills, crash loops, and unusual telemetry endpoint changes.
• If suspicious activity is found, preserve application logs, container events, egress flow logs, and collector/proxy access logs for investigation.