go package report

Is go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp safe?

1 known vulnerability, worst severity MODERATE.

// reach

0 direct dependencies

none carry a known advisory

    0 packages depend on it

    an advisory here reaches each of them

      Create a free accountfor every dependency path, dependent and what to upgrade
      // ai model usage

      Tracked for PyPI packages. HuggingFace models declare Python dependencies, so go packages are not covered.


      cvss
      0.0
      medium

      severity out of 10

      epss
      0.00%
      low

      chance of exploitation in 30 days, 8th percentile of all CVEs

      xyz score
      not scored

      CyberXYZ composite out of 10

      fig. 01 — GHSA-w8rr-5gcm-pp58, the advisory selected below

      // 1 advisories

      GHSA-w8rr-5gcm-pp58

      MODERATECVE-2026-39882

      overview: this report shows that the otlp HTTP exporters (traces/metrics/logs) read the full HTTP response body into an in-memory bytes.Buffer 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).

      severity

      HIGH

      not claiming: this is a remote dos against every default deployment. claiming: if the exporter sends traces to an untrusted collector endpoint (or over a network segment where mitm is realistic), that endpoint can crash the process via a large response body.

      callsite (pinned):

      • exporters/otlp/otlptrace/otlptracehttp/client.go:199
      • exporters/otlp/otlptrace/otlptracehttp/client.go:230
      • exporters/otlp/otlpmetric/otlpmetrichttp/client.go:170
      • exporters/otlp/otlpmetric/otlpmetrichttp/client.go:201
      • exporters/otlp/otlplog/otlploghttp/client.go:190
      • exporters/otlp/otlplog/otlploghttp/client.go:221

      permalinks (pinned):

      root cause: each exporter client reads resp.Body using io.Copy(&respData, resp.Body) into a bytes.Buffer on both success and error paths, with no upper bound.

      impact: a malicious collector can force large transient heap allocations during export (peak memory scales with attacker-chosen response size) and can potentially crash the instrumented process (oom).

      affected component:

      • go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp
      • go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp
      • go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp

      repro (local-only):

      unzip poc.zip -d poc
      cd poc
      make canonical resp_bytes=33554432 chunk_delay_ms=0

      expected output contains:

      [CALLSITE_HIT]: otlptracehttp.UploadTraces::io.Copy(resp.Body)
      [PROOF_MARKER]: resp_bytes=33554432 peak_alloc_bytes=118050512

      control (same env, patched target):

      unzip poc.zip -d poc
      cd poc
      make control resp_bytes=33554432 chunk_delay_ms=0

      expected control output contains:

      [CALLSITE_HIT]: otlptracehttp.UploadTraces::io.Copy(resp.Body)
      [NC_MARKER]: resp_bytes=33554432 peak_alloc_bytes=512232

      attachments: poc.zip (attached)

      PRDESCRIPTION.md

      attackscenario.md

      poc.zip

      Fixed in: https://github.com/open-telemetry/opentelemetry-go/pull/8108

      // cvss v3.1 vector

      CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

      Attack vector
      Adjacent
      Attack complexity
      High
      Privileges required
      None
      User interaction
      None
      Scope
      Unchanged
      Confidentiality
      None
      Integrity
      None
      Availability
      High

      Checked 2026-09-27 at 21:41 UTC. The most recent advisory here was published 2026-04-08. Updated continuously from NVD, GHSA, OSV and CNA feeds.

      Think a verdict here is wrong? Tell us — we respond within 2 business days.