chore(deps): update opentelemetry-go monorepo#32
Open
renovate-sh-app[bot] wants to merge 1 commit into
Open
Conversation
| datasource | package | from | to | | ---------- | --------------------------------------------------------------- | ------- | ------- | | go | go.opentelemetry.io/otel | v1.40.0 | v1.41.0 | | go | go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp | v1.38.0 | v1.43.0 | | go | go.opentelemetry.io/otel/sdk | v1.40.0 | v1.43.0 | Signed-off-by: renovate-sh-app[bot] <219655108+renovate-sh-app[bot]@users.noreply.github.com>
Contributor
Author
ℹ️ Artifact update noticeFile name: go.modIn order to perform the update(s) described in the table above, Renovate ran the
Details:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
v1.40.0→v1.41.0v1.38.0→v1.43.0v1.40.0→v1.43.0OpenTelemetry-Go: multi-value
baggageheader extraction causes excessive allocations (remote dos amplification)CVE-2026-29181 / GHSA-mh2q-q3fh-2475
More information
Details
multi-value
baggage:header extraction parses each header field-value independently and aggregates members across values. this allows an attacker to amplify cpu and allocations by sending manybaggage:header lines, even when each individual value is within the 8192-byte per-value parse limit.severity
HIGH (availability / remote request amplification)
relevant links
vulnerability details
pins: open-telemetry/opentelemetry-go@1ee4a41
as-of: 2026-02-04
policy: direct (no program scope provided)
callsite: propagation/baggage.go:58 (
extractMultiBaggage)attacker control: inbound HTTP request headers (many
baggagefield-values) →propagation.HeaderCarrier.Values("baggage")→ repeatedbaggage.Parse+ member aggregationroot cause
extractMultiBaggageiterates over allbaggageheader field-values and parses each one independently, then appends members into a shared slice. the 8192-byte parsing cap applies per header value, but the multi-value path repeats that work once per header line (bounded only by the server/proxy header byte limit).impact
in a default
net/httpconfiguration (max header bytes 1mb), a single request with manybaggage:header field-values can cause large per-request allocations and increased latency.example from the attached PoC harness (darwin/arm64; 80 values; 40 requests):
per_req_alloc_bytes=10315458andp95_ms=7per_req_alloc_bytes=133429andp95_ms=0proof of concept
canonical:
output (excerpt):
control:
cd poc make controlcontrol output (excerpt):
expected: multiple
baggageheader field-values should be semantically equivalent to a single comma-joinedbaggagevalue and should not multiply parsing/alloc work within the effective header byte budget.actual: multiple
baggageheader field-values trigger repeated parsing and member aggregation, causing high per-request allocations and increased latency even when each individual value is within 8192 bytes.fix recommendation
avoid repeated parsing across multi-values by enforcing a global budget and/or normalizing multi-values into a single value before parsing. one mitigation approach is to treat multi-values as a single comma-joined string and cap total parsed bytes (for example 8192 bytes total).
fix accepted when: under the default PoC harness settings, canonical stays within 2x of control for
per_req_alloc_bytesandper_req_allocs, andp95_msstays below 2ms.poc.zip
PR_DESCRIPTION.md
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
OpenTelemetry-Go: multi-value
baggageheader extraction causes excessive allocations (remote dos amplification)CVE-2026-29181 / GHSA-mh2q-q3fh-2475
More information
Details
multi-value
baggage:header extraction parses each header field-value independently and aggregates members across values. this allows an attacker to amplify cpu and allocations by sending manybaggage:header lines, even when each individual value is within the 8192-byte per-value parse limit.severity
HIGH (availability / remote request amplification)
relevant links
vulnerability details
pins: open-telemetry/opentelemetry-go@1ee4a41
as-of: 2026-02-04
policy: direct (no program scope provided)
callsite: propagation/baggage.go:58 (
extractMultiBaggage)attacker control: inbound HTTP request headers (many
baggagefield-values) →propagation.HeaderCarrier.Values("baggage")→ repeatedbaggage.Parse+ member aggregationroot cause
extractMultiBaggageiterates over allbaggageheader field-values and parses each one independently, then appends members into a shared slice. the 8192-byte parsing cap applies per header value, but the multi-value path repeats that work once per header line (bounded only by the server/proxy header byte limit).impact
in a default
net/httpconfiguration (max header bytes 1mb), a single request with manybaggage:header field-values can cause large per-request allocations and increased latency.example from the attached PoC harness (darwin/arm64; 80 values; 40 requests):
per_req_alloc_bytes=10315458andp95_ms=7per_req_alloc_bytes=133429andp95_ms=0proof of concept
canonical:
output (excerpt):
control:
cd poc make controlcontrol output (excerpt):
expected: multiple
baggageheader field-values should be semantically equivalent to a single comma-joinedbaggagevalue and should not multiply parsing/alloc work within the effective header byte budget.actual: multiple
baggageheader field-values trigger repeated parsing and member aggregation, causing high per-request allocations and increased latency even when each individual value is within 8192 bytes.fix recommendation
avoid repeated parsing across multi-values by enforcing a global budget and/or normalizing multi-values into a single value before parsing. one mitigation approach is to treat multi-values as a single comma-joined string and cap total parsed bytes (for example 8192 bytes total).
fix accepted when: under the default PoC harness settings, canonical stays within 2x of control for
per_req_alloc_bytesandper_req_allocs, andp95_msstays below 2ms.poc.zip
PR_DESCRIPTION.md
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
opentelemetry-go: OTLP HTTP exporters read unbounded HTTP response bodies
CVE-2026-39882 / GHSA-w8rr-5gcm-pp58
More information
Details
overview:
this report shows that the otlp HTTP exporters (traces/metrics/logs) read the full HTTP response body into an in-memory
bytes.Bufferwithout 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):
permalinks (pinned):
root cause:
each exporter client reads
resp.Bodyusingio.Copy(&respData, resp.Body)into abytes.Bufferon 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:
repro (local-only):
unzip poc.zip -d poc cd poc make canonical resp_bytes=33554432 chunk_delay_ms=0expected output contains:
control (same env, patched target):
unzip poc.zip -d poc cd poc make control resp_bytes=33554432 chunk_delay_ms=0expected control output contains:
attachments: poc.zip (attached)
PR_DESCRIPTION.md
attack_scenario.md
poc.zip
Fixed in: https://github.com/open-telemetry/opentelemetry-go/pull/8108
Severity
CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
opentelemetry-go: OTLP HTTP exporters read unbounded HTTP response bodies
CVE-2026-39882 / GHSA-w8rr-5gcm-pp58
More information
Details
overview:
this report shows that the otlp HTTP exporters (traces/metrics/logs) read the full HTTP response body into an in-memory
bytes.Bufferwithout 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):
permalinks (pinned):
root cause:
each exporter client reads
resp.Bodyusingio.Copy(&respData, resp.Body)into abytes.Bufferon 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:
repro (local-only):
unzip poc.zip -d poc cd poc make canonical resp_bytes=33554432 chunk_delay_ms=0expected output contains:
control (same env, patched target):
unzip poc.zip -d poc cd poc make control resp_bytes=33554432 chunk_delay_ms=0expected control output contains:
attachments: poc.zip (attached)
PR_DESCRIPTION.md
attack_scenario.md
poc.zip
Fixed in: https://github.com/open-telemetry/opentelemetry-go/pull/8108
Severity
CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
opentelemetry-go: BSD kenv command not using absolute path enables PATH hijacking
CVE-2026-39883 / GHSA-hfvc-g4fc-pqhx
More information
Details
Summary
The fix for GHSA-9h8m-3fm2-qjrq (CVE-2026-24051) changed the Darwin
ioregcommand to use an absolute path but left the BSDkenvcommand using a bare name, allowing the same PATH hijacking attack on BSD and Solaris platforms.Root Cause
sdk/resource/host_id.goline 42:Compare with the fixed Darwin path at line 58:
The
execCommandhelper atsdk/resource/host_id_exec.gousesexec.Command(name, arg...)which searches$PATHwhen the command name contains no path separator.Affected platforms (per build tag in
host_id_bsd.go:4): DragonFly BSD, FreeBSD, NetBSD, OpenBSD, Solaris.The
kenvpath is reached when/etc/hostiddoes not exist (line 38-40), which is common on FreeBSD systems.Attack
go.opentelemetry.io/otel/sdkkenvbinary earlier in$PATHhostIDReaderBSD.read()callsexec.Command("kenv", ...)which resolves to the malicious binarySame attack vector and impact as CVE-2026-24051.
Suggested Fix
Use the absolute path:
On FreeBSD,
kenvis located at/bin/kenv.Severity
CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
opentelemetry-go: BSD kenv command not using absolute path enables PATH hijacking
CVE-2026-39883 / GHSA-hfvc-g4fc-pqhx
More information
Details
Summary
The fix for GHSA-9h8m-3fm2-qjrq (CVE-2026-24051) changed the Darwin
ioregcommand to use an absolute path but left the BSDkenvcommand using a bare name, allowing the same PATH hijacking attack on BSD and Solaris platforms.Root Cause
sdk/resource/host_id.goline 42:Compare with the fixed Darwin path at line 58:
The
execCommandhelper atsdk/resource/host_id_exec.gousesexec.Command(name, arg...)which searches$PATHwhen the command name contains no path separator.Affected platforms (per build tag in
host_id_bsd.go:4): DragonFly BSD, FreeBSD, NetBSD, OpenBSD, Solaris.The
kenvpath is reached when/etc/hostiddoes not exist (line 38-40), which is common on FreeBSD systems.Attack
go.opentelemetry.io/otel/sdkkenvbinary earlier in$PATHhostIDReaderBSD.read()callsexec.Command("kenv", ...)which resolves to the malicious binarySame attack vector and impact as CVE-2026-24051.
Suggested Fix
Use the absolute path:
On FreeBSD,
kenvis located at/bin/kenv.Severity
CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Release Notes
open-telemetry/opentelemetry-go (go.opentelemetry.io/otel)
v1.41.0Compare Source
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
Need help?
You can ask for more help in the following Slack channel: #proj-renovate-self-hosted. In that channel you can also find ADR and FAQ docs in the Resources section.