Update dependency io.opentelemetry:opentelemetry-api to v1.62.0 [SECURITY] (main)#49
Draft
renovatebot-confluentinc[bot] wants to merge 1 commit into
Conversation
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.
For any questions/concerns about this PR, please review the Renovate Bot wiki/FAQs, or the #renovatebot Slack channel.
This PR contains the following updates:
1.49.0→1.62.01.43.0→1.62.0Warning
Some dependencies could not be looked up. Check the warning logs for more information.
OpenTelemetry Java SDK has Unbounded Memory Allocation in W3C Baggage Propagation
CVE-2026-45292 / GHSA-rcgg-9c38-7xpx
More information
Details
Overview
A vulnerability affects the baggage propagation implementation in
opentelemetry-apiandopentelemetry-extension-trace-propagators. Parsing oversized baggagecauses unbounded memory allocation and CPU consumption. Because baggage is automatically
re-injected into every outgoing request, the effect can fan out to downstream services that
never received the original malicious request.
Technical Details
W3CBaggagePropagatordid not enforce any limit on the total size or entry count of thebaggageheader. The parser iterated character-by-character through the entire valueregardless of length.
JaegerPropagatorandOtTracePropagatorhad the same gap in their respective baggageextraction paths.
these limits were enforced.
Impact
The practical availability impact for most deployments is limited. Every major Java HTTP server
enforces its own header size limit (Tomcat, Jetty, Netty, Vert.x, and gRPC-Java all default to
8 KiB), constraining what an external attacker can deliver before the application is reached.
The risk is higher when transport-layer limits are absent — e.g., a compromised internal service
communicating over a non-HTTP or custom transport.
Remediation
Update to version 1.62.0 or later (#8380).
The fix enforces limits consistent with the W3C Baggage specification at the propagator level:
baggageheader valuesHeaders that would exceed either limit are dropped at the point the limit is reached;
already-extracted valid entries are retained.
Workarounds
Ensure HTTP header size limits are configured at the server or gateway level. Most Java HTTP
servers enforce an 8 KiB header limit by default, which mitigates external attack vectors
independently of this fix.
References
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:LReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
OpenTelemetry Java SDK has Unbounded Memory Allocation in W3C Baggage Propagation
CVE-2026-45292 / GHSA-rcgg-9c38-7xpx
More information
Details
Overview
A vulnerability affects the baggage propagation implementation in
opentelemetry-apiandopentelemetry-extension-trace-propagators. Parsing oversized baggagecauses unbounded memory allocation and CPU consumption. Because baggage is automatically
re-injected into every outgoing request, the effect can fan out to downstream services that
never received the original malicious request.
Technical Details
W3CBaggagePropagatordid not enforce any limit on the total size or entry count of thebaggageheader. The parser iterated character-by-character through the entire valueregardless of length.
JaegerPropagatorandOtTracePropagatorhad the same gap in their respective baggageextraction paths.
these limits were enforced.
Impact
The practical availability impact for most deployments is limited. Every major Java HTTP server
enforces its own header size limit (Tomcat, Jetty, Netty, Vert.x, and gRPC-Java all default to
8 KiB), constraining what an external attacker can deliver before the application is reached.
The risk is higher when transport-layer limits are absent — e.g., a compromised internal service
communicating over a non-HTTP or custom transport.
Remediation
Update to version 1.62.0 or later (#8380).
The fix enforces limits consistent with the W3C Baggage specification at the propagator level:
baggageheader valuesHeaders that would exceed either limit are dropped at the point the limit is reached;
already-extracted valid entries are retained.
Workarounds
Ensure HTTP header size limits are configured at the server or gateway level. Most Java HTTP
servers enforce an 8 KiB header limit by default, which mitigates external attack vectors
independently of this fix.
References
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:LReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.
This PR has been generated by Mend Renovate.