Skip to content

chore(deps): update security updates [security]#190

Merged
NumaryBot merged 1 commit into
mainfrom
renovate/security
Apr 9, 2026
Merged

chore(deps): update security updates [security]#190
NumaryBot merged 1 commit into
mainfrom
renovate/security

Conversation

@NumaryBot
Copy link
Copy Markdown
Contributor

@NumaryBot NumaryBot commented Apr 4, 2026

This PR contains the following updates:

Package Type Update Change
github.com/go-jose/go-jose/v4 indirect patch v4.1.3 -> v4.1.4
go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp indirect minor v1.42.0 -> v1.43.0
go.opentelemetry.io/otel/sdk indirect minor v1.42.0 -> v1.43.0

GitHub Vulnerability Alerts

CVE-2026-34986

Impact

Decrypting a JSON Web Encryption (JWE) object will panic if the alg field indicates a key wrapping algorithm (one ending in KW, with the exception of A128GCMKW, A192GCMKW, and A256GCMKW) and the encrypted_key field is empty. The panic happens when cipher.KeyUnwrap() in key_wrap.go attempts to allocate a slice with a zero or negative length based on the length of the encrypted_key.

This code path is reachable from ParseEncrypted() / ParseEncryptedJSON() / ParseEncryptedCompact() followed by Decrypt() on the resulting object. Note that the parse functions take a list of accepted key algorithms. If the accepted key algorithms do not include any key wrapping algorithms, parsing will fail and the application will be unaffected.

This panic is also reachable by calling cipher.KeyUnwrap() directly with any ciphertext parameter less than 16 bytes long, but calling this function directly is less common.

Panics can lead to denial of service.

Fixed In

4.1.4 and v3.0.5

Workarounds

If the list of keyAlgorithms passed to ParseEncrypted() / ParseEncryptedJSON() / ParseEncryptedCompact() does not include key wrapping algorithms (those ending in KW), your application is unaffected.

If your application uses key wrapping, you can prevalidate to the JWE objects to ensure the encrypted_key field is nonempty. If your application accepts JWE Compact Serialization, apply that validation to the corresponding field of that serialization (the data between the first and second .).

Thanks

Thanks to Datadog's Security team for finding this issue.


Go JOSE Panics in JWE decryption

CVE-2026-34986 / GHSA-78h2-9frx-2jm8

More information

Details

Impact

Decrypting a JSON Web Encryption (JWE) object will panic if the alg field indicates a key wrapping algorithm (one ending in KW, with the exception of A128GCMKW, A192GCMKW, and A256GCMKW) and the encrypted_key field is empty. The panic happens when cipher.KeyUnwrap() in key_wrap.go attempts to allocate a slice with a zero or negative length based on the length of the encrypted_key.

This code path is reachable from ParseEncrypted() / ParseEncryptedJSON() / ParseEncryptedCompact() followed by Decrypt() on the resulting object. Note that the parse functions take a list of accepted key algorithms. If the accepted key algorithms do not include any key wrapping algorithms, parsing will fail and the application will be unaffected.

This panic is also reachable by calling cipher.KeyUnwrap() directly with any ciphertext parameter less than 16 bytes long, but calling this function directly is less common.

Panics can lead to denial of service.

Fixed In

4.1.4 and v3.0.5

Workarounds

If the list of keyAlgorithms passed to ParseEncrypted() / ParseEncryptedJSON() / ParseEncryptedCompact() does not include key wrapping algorithms (those ending in KW), your application is unaffected.

If your application uses key wrapping, you can prevalidate to the JWE objects to ensure the encrypted_key field is nonempty. If your application accepts JWE Compact Serialization, apply that validation to the corresponding field of that serialization (the data between the first and second .).

Thanks

Thanks to Datadog's Security team for finding this issue.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

CVE-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)

PR_DESCRIPTION.md

attack_scenario.md

poc.zip

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


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.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)

PR_DESCRIPTION.md

attack_scenario.md

poc.zip

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

Severity

  • CVSS Score: 5.3 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

CVE-2026-39883

Summary

The fix for GHSA-9h8m-3fm2-qjrq (CVE-2026-24051) changed the Darwin ioreg command to use an absolute path but left the BSD kenv command using a bare name, allowing the same PATH hijacking attack on BSD and Solaris platforms.

Root Cause

sdk/resource/host_id.go line 42:

if result, err := r.execCommand("kenv", "-q", "smbios.system.uuid"); err == nil {

Compare with the fixed Darwin path at line 58:

result, err := r.execCommand("/usr/sbin/ioreg", "-rd1", "-c", "IOPlatformExpertDevice")

The execCommand helper at sdk/resource/host_id_exec.go uses exec.Command(name, arg...) which searches $PATH when 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 kenv path is reached when /etc/hostid does not exist (line 38-40), which is common on FreeBSD systems.

Attack

  1. Attacker has local access to a system running a Go application that imports go.opentelemetry.io/otel/sdk
  2. Attacker places a malicious kenv binary earlier in $PATH
  3. Application initializes OpenTelemetry resource detection at startup
  4. hostIDReaderBSD.read() calls exec.Command("kenv", ...) which resolves to the malicious binary
  5. Arbitrary code executes in the context of the application

Same attack vector and impact as CVE-2026-24051.

Suggested Fix

Use the absolute path:

if result, err := r.execCommand("/bin/kenv", "-q", "smbios.system.uuid"); err == nil {

On FreeBSD, kenv is located at /bin/kenv.


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 ioreg command to use an absolute path but left the BSD kenv command using a bare name, allowing the same PATH hijacking attack on BSD and Solaris platforms.

Root Cause

sdk/resource/host_id.go line 42:

if result, err := r.execCommand("kenv", "-q", "smbios.system.uuid"); err == nil {

Compare with the fixed Darwin path at line 58:

result, err := r.execCommand("/usr/sbin/ioreg", "-rd1", "-c", "IOPlatformExpertDevice")

The execCommand helper at sdk/resource/host_id_exec.go uses exec.Command(name, arg...) which searches $PATH when 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 kenv path is reached when /etc/hostid does not exist (line 38-40), which is common on FreeBSD systems.

Attack
  1. Attacker has local access to a system running a Go application that imports go.opentelemetry.io/otel/sdk
  2. Attacker places a malicious kenv binary earlier in $PATH
  3. Application initializes OpenTelemetry resource detection at startup
  4. hostIDReaderBSD.read() calls exec.Command("kenv", ...) which resolves to the malicious binary
  5. Arbitrary code executes in the context of the application

Same attack vector and impact as CVE-2026-24051.

Suggested Fix

Use the absolute path:

if result, err := r.execCommand("/bin/kenv", "-q", "smbios.system.uuid"); err == nil {

On FreeBSD, kenv is located at /bin/kenv.

Severity

  • CVSS Score: Unknown
  • Vector String: CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).


Release Notes

go-jose/go-jose (github.com/go-jose/go-jose/v4)

v4.1.4

Compare Source

What's Changed

Fixes Panic in JWE decryption. See GHSA-78h2-9frx-2jm8

Full Changelog: go-jose/go-jose@v4.1.3...v4.1.4

open-telemetry/opentelemetry-go (go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp)

v1.43.0: /v0.65.0/v0.19.0

Compare Source

Added
  • Add IsRandom and WithRandom on TraceFlags, and IsRandom on SpanContext in go.opentelemetry.io/otel/trace
    for W3C Trace Context Level 2 Random Trace ID Flag support. (#​8012)
  • Add service detection with WithService in go.opentelemetry.io/otel/sdk/resource. (#​7642)
  • Add DefaultWithContext and EnvironmentWithContext in go.opentelemetry.io/otel/sdk/resource to support plumbing context.Context through default and environment detectors. (#​8051)
  • Support attributes with empty value (attribute.EMPTY) in go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc. (#​8038)
  • Support attributes with empty value (attribute.EMPTY) in go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetricgrpc. (#​8038)
  • Support attributes with empty value (attribute.EMPTY) in go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploggrpc. (#​8038)
  • Support attributes with empty value (attribute.EMPTY) in go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp. (#​8038)
  • Support attributes with empty value (attribute.EMPTY) in go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp. (#​8038)
  • Support attributes with empty value (attribute.EMPTY) in go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp. (#​8038)
  • Support attributes with empty value (attribute.EMPTY) in go.opentelemetry.io/otel/sdk/metric/metricdata/metricdatatest. (#​8038)
  • Add support for per-series start time tracking for cumulative metrics in go.opentelemetry.io/otel/sdk/metric.
    Set OTEL_GO_X_PER_SERIES_START_TIMESTAMPS=true to enable. (#​8060)
  • Add WithCardinalityLimitSelector for metric reader for configuring cardinality limits specific to the instrument kind. (#​7855)
Changed
  • Introduce the EMPTY Type in go.opentelemetry.io/otel/attribute to reflect that an empty value is now a valid value, with INVALID remaining as a deprecated alias of EMPTY. (#​8038)
  • Refactor slice handling in go.opentelemetry.io/otel/attribute to optimize short slice values with fixed-size fast paths. (#​8039)
  • Improve performance of span metric recording in go.opentelemetry.io/otel/sdk/trace by returning early if self-observability is not enabled. (#​8067)
  • Improve formatting of metric data diffs in go.opentelemetry.io/otel/sdk/metric/metricdata/metricdatatest. (#​8073)
Deprecated
  • Deprecate INVALID in go.opentelemetry.io/otel/attribute. Use EMPTY instead. (#​8038)
Fixed
  • Return spec-compliant TraceIdRatioBased description. This is a breaking behavioral change, but it is necessary to
    make the implementation spec-compliant. (#​8027)
  • Fix a race condition in go.opentelemetry.io/otel/sdk/metric where the lastvalue aggregation could collect the value 0 even when no zero-value measurements were recorded. (#​8056)
  • Limit HTTP response body to 4 MiB in go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp to mitigate excessive memory usage caused by a misconfigured or malicious server.
    Responses exceeding the limit are treated as non-retryable errors. (#​8108)
  • Limit HTTP response body to 4 MiB in go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp to mitigate excessive memory usage caused by a misconfigured or malicious server.
    Responses exceeding the limit are treated as non-retryable errors. (#​8108)
  • Limit HTTP response body to 4 MiB in go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp to mitigate excessive memory usage caused by a misconfigured or malicious server.
    Responses exceeding the limit are treated as non-retryable errors. (#​8108)
  • WithHostID detector in go.opentelemetry.io/otel/sdk/resource to use full path for kenv command on BSD. (#​8113)
  • Fix missing request.GetBody in go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp to correctly handle HTTP2 GOAWAY frame. (#​8096)
What's Changed
New Contributors

Full Changelog: open-telemetry/opentelemetry-go@v1.42.0...v1.43.0


Configuration

📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.


  • If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

@NumaryBot NumaryBot requested a review from a team as a code owner April 4, 2026 03:00
@NumaryBot NumaryBot enabled auto-merge (squash) April 4, 2026 03:00
@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Apr 4, 2026

Important

Review skipped

Review was skipped due to path filters

⛔ Files ignored due to path filters (2)
  • go.mod is excluded by !**/*.mod
  • go.sum is excluded by !**/*.sum, !**/*.sum

CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including **/dist/** will override the default block on the dist directory, by removing the pattern from both the lists.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 4c392883-94fc-4876-a94d-ff8a54002f7a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch renovate/security

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@NumaryBot NumaryBot force-pushed the renovate/security branch from f217068 to 68631b1 Compare April 9, 2026 03:02
@NumaryBot NumaryBot changed the title chore(deps): update module github.com/go-jose/go-jose/v4 to v4.1.4 [security] chore(deps): update security updates [security] Apr 9, 2026
@NumaryBot
Copy link
Copy Markdown
Contributor Author

ℹ Artifact update notice

File name: go.mod

In order to perform the update(s) described in the table above, Renovate ran the go get command, which resulted in the following additional change(s):

  • 7 additional dependencies were updated

Details:

Package Change
go.opentelemetry.io/otel v1.42.0 -> v1.43.0
go.opentelemetry.io/otel/trace v1.42.0 -> v1.43.0
google.golang.org/grpc v1.79.3 -> v1.80.0
go.opentelemetry.io/otel/exporters/otlp/otlptrace v1.42.0 -> v1.43.0
go.opentelemetry.io/otel/metric v1.42.0 -> v1.43.0
google.golang.org/genproto/googleapis/api v0.0.0-20260319201613-d00831a3d3e7 -> v0.0.0-20260401024825-9d38bb4040a9
google.golang.org/genproto/googleapis/rpc v0.0.0-20260319201613-d00831a3d3e7 -> v0.0.0-20260401024825-9d38bb4040a9

@NumaryBot NumaryBot merged commit 3c9916d into main Apr 9, 2026
8 checks passed
@NumaryBot NumaryBot deleted the renovate/security branch April 9, 2026 15:37
@codecov
Copy link
Copy Markdown

codecov Bot commented Apr 9, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 0.00%. Comparing base (58497c1) to head (68631b1).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files
@@     Coverage Diff     @@
##   main   #190   +/-   ##
===========================
===========================

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants