[scality-renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
golang.org/x/net	v0.57.0 → v0.62.0

---

HTTP/2 server memory exhaustion due to Trailer headers in net/http

BIT-golang-2026-78659 / CVE-2026-78659 / GO-2026-6603

More information

Details

When "Trailer" headers are sent by a client, the HTTP server internally uses the header values to populate the Request.Trailer map passed to the server handler. Because Request.Trailer is a map, each entry incurs memory overhead. For HTTP/2 servers, a malicious client can exploit this by sending a "Trailer" header that declares a large number of fields, causing the server to allocate a disproportionate amount of memory while bypassing Server.MaxHeaderValueCount and Server.MaxHeaderBytes limits. This exploit is not applicable for HTTP/1 servers, which do not support multiplexing a large number of requests over one TCP connection, and whose Server.MaxHeaderBytes are calculated differently.

Severity

Unknown

References

• https://go.dev/cl/847185
• https://go.dev/cl/847314
• https://go.dev/issue/81857
• https://groups.google.com/g/golang-announce/c/U2fTuyDJznI
• https://groups.google.com/g/golang-announce/c/ZPwCyRUuGBs

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

---

HTTP/2 transport accepts malformed framing-related headers in net/http

BIT-golang-2026-78660 / CVE-2026-78660 / GO-2026-6610

More information

Details

Historically, we have been rather lax about malformed framing-related headers in our HTTP/2 implementation, as they cannot interfere with HTTP/2 framing. However, this makes it possible for our HTTP/2 implementation to forward responses containing such headers to an HTTP/1 client when acting as a reverse proxy. If the HTTP/1 client also does not behave strictly enough, this can result in response smuggling.

Severity

Unknown

References

• https://go.dev/cl/835145
• https://go.dev/cl/836385
• https://go.dev/issue/81115
• https://groups.google.com/g/golang-announce/c/U2fTuyDJznI

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

---

Excessive CPU consumption from repeated initial window changes in net/http

BIT-golang-2026-78669 / CVE-2026-78669 / GO-2026-6611

More information

Details

A malicious HTTP/2 peer can cause excessive CPU consumption in the client or server by opening a large number of streams and then sending many small SETTINGS frames containing SETTINGS_INITIAL_WINDOW_SIZE values.

Severity

Unknown

References

• https://go.dev/cl/847186
• https://go.dev/cl/847308
• https://go.dev/issue/81742
• https://groups.google.com/g/golang-announce/c/U2fTuyDJznI
• https://groups.google.com/g/golang-announce/c/ZPwCyRUuGBs

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

---

Double flow control refund on HTTP/2 server streams in net/http

BIT-golang-2026-78663 / CVE-2026-78663 / GO-2026-6612

More information

Details

The HTTP/2 server can refund connection-level flow control twice for the same data: Once when a client resets a stream (refunding data for any sent-but-unread portion of the stream), and again when a request handler reads the buffered data. A malicious client can exploit this to bypass the configured connection-level flow control limit (MaxReceiveBufferPerConnection). Total buffered data is still limited by the concurrent stream limit and stream-level flow control.

Severity

Unknown

References

• https://go.dev/cl/847187
• https://go.dev/cl/847310
• https://go.dev/issue/81743
• https://groups.google.com/g/golang-announce/c/U2fTuyDJznI
• https://groups.google.com/g/golang-announce/c/ZPwCyRUuGBs

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

---

HTTP/2 server crash due to HPACK encoder race in net/http

BIT-golang-2026-97032 / CVE-2026-97032 / GO-2026-6617

More information

Details

HTTP/2 servers could end up crashing due to inadvertently modifying its HPACK encoder concurrently. This happens because the server modifies the HPACK encoder from two goroutines without synchronization: one uses the encoder to encode a HEADERS frame as part of a response sent to a client and the other modifies the encoder's table size when handling a SETTINGS frame containing SETTINGS_HEADER_TABLE_SIZE that a client sends. A malicious client can repeatedly send a request while changing the header table size to crash the server.

Severity

Unknown

References

• https://go.dev/cl/847188
• https://go.dev/cl/847313
• https://go.dev/issue/81867
• https://groups.google.com/g/golang-announce/c/U2fTuyDJznI
• https://groups.google.com/g/golang-announce/c/ZPwCyRUuGBs

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

---

Avoid quadratic complexity when coalescing text nodes in html in golang.org/x/net

CVE-2026-78661 / GO-2026-6860

More information

Details

When coalescing adjacent text nodes in addText and fosterParent, appending to an existing TextNode's Data via string concatenation (n.Data += text) reallocated and copied the accumulated string on every token. Inputs containing many short text runs separated by ignored end tags (such as "a") caused O(n^2) allocations and byte copies.

Accumulate coalesced text in per-node byte slices during parsing and materialize Data strings once at the end of parse.

Severity

Unknown

References

• https://go.dev/cl/849365
• https://go.dev/issue/82224
• https://groups.google.com/g/golang-announce/c/sqrs2vTx_Xs

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

---

Check all ancestor namespace transitions when rendering raw text in html in golang.org/x/net

CVE-2026-97045 / GO-2026-6866

More information

Details

In childTextNodesAreLiteral, walking up the tree previously stopped at the nearest foreign ancestor once an HTML integration point was found. However, that integration point may itself be a descendant of an element that was foster-parented into a foreign namespace (such as or fostered under ), causing a parser to resolve the subtree in a different foreign namespace upon re-parsing the rendered output.

Continue walking the full ancestor chain and verify that every transition from a non-empty namespace occurs at an HTML integration point before emitting literal text.

Severity

Unknown

References

• https://go.dev/cl/855121
• https://go.dev/issue/82622
• https://groups.google.com/g/golang-announce/c/sqrs2vTx_Xs

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

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 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 this update again.

---

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

---

This PR has been generated by Mend Renovate CLI.

[scality-renovate]

ℹ️ 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):

• 6 additional dependencies were updated

Details:

Package	Change
golang.org/x/mod	v0.37.0 -> v0.41.0
golang.org/x/sync	v0.22.0 -> v0.24.0
golang.org/x/sys	v0.47.0 -> v0.49.0
golang.org/x/term	v0.45.0 -> v0.47.0
golang.org/x/text	v0.40.0 -> v0.43.0
golang.org/x/tools	v0.47.0 -> v0.51.0

[github-actions]

Dependency Bump Evaluation

Version change: golang.org/x/net v0.57.0 -> v0.62.0 (indirect)
Semver bump type: minor (pre-1.0, 5 minor releases)

Changes:

• golang.org/x/net v0.57.0 -> v0.62.0, a security update
• Other golang.org/x modules move up with it (all indirect): mod v0.37.0 -> v0.41.0, sync v0.22.0 -> v0.24.0, sys v0.47.0 -> v0.49.0, term v0.45.0 -> v0.47.0, text v0.40.0 -> v0.43.0, tools v0.47.0 -> v0.51.0
• Only go.mod and go.sum change. No code changes.

Breaking changes: None known. golang.org/x/net keeps its API backward compatible, and this repo does not import golang.org/x/net directly. It only comes in through client-go, apimachinery and controller-runtime.

Security concerns: None introduced. The bump fixes these advisories:

• x/net/http2: Trailer header memory exhaustion (GO-2026-6603), malformed framing-related headers accepted by the transport (GO-2026-6610), CPU exhaustion from repeated SETTINGS_INITIAL_WINDOW_SIZE changes (GO-2026-6611), double connection-level flow-control refund (GO-2026-6612), server crash from an HPACK encoder race (GO-2026-6617)
• x/net/html: quadratic cost when coalescing text nodes (GO-2026-6860), namespace check when rendering raw text (GO-2026-6866)

Impact on codebase: No direct imports of golang.org/x/net. The HTTP/2 fixes matter most, because client-go uses x/net/http2 for its connections to the API server. The operator's metrics and webhook servers turn HTTP/2 off by default (--enable-http2=false in cmd/main.go), so they were already less exposed to the server-side issues. The operator does not parse HTML, so the x/net/html fixes do not apply to it.

Recommendation: REVIEW REQUIRED

Notes: The changes look low risk, and the security fixes make this worth merging soon. Two things stop an automatic approval:

1. CI (build, lint, test, test-e2e, generate) was still running when this was written. Merge only once they all pass.
2. The commit author is scality-renovate[bot], not dependabot, so this review can only comment. A human needs to approve.

Updated after rebase: the target version is now v0.62.0. The earlier evaluation was written against v0.60.0.

— Claude Code