[main] Update osv-vulnerability-alerts [SECURITY] (main)

[ospk8s-renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
golang.org/x/net	v0.58.0 → v0.60.0
golang.org/x/net	v0.57.0 → v0.60.0
google.golang.org/grpc	v1.83.1 → v1.83.2

---

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

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

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

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

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

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

---

gRPC-Go xDS servers: Denial of Service (DoS) via crash due to missing :authority and Host headers

CVE-2026-84445 / GHSA-2v4p-qf9q-27wj / GO-2026-6443

More information

Details

A vulnerability exists in gRPC-Go servers configured with xds.NewGRPCServer() where a crafted request missing both :authority and Host headers can cause a server panic, resulting in a Denial of Service (DoS).

Servers built with xds.NewGRPCServer install an xDS routing interceptor on every RPC. This interceptor looks up the request’s :authority header to pick a virtual host. The HTTP/2 server transport previously accepted requests that had neither :authority nor Host. When this happened, the xDS routing interceptor attempted to access the first element of an empty slice of authorities, leading to an index out of bounds panic. Since the per-RPC goroutine does not recover from panics, the entire server process would terminate.

This panic occurs in the interceptor pipeline, meaning the transport credentials handshake (TLS, mTLS, or ALTS) and HTTP/2 connection establishment must complete successfully before the crafted request can reach this logic.

• Insecure/Standard TLS: If the server permits insecure (plaintext) connections or standard credentials (where client certs are not checked), any unauthenticated remote attacker can trigger the crash.
• mTLS / ALTS: If strict transport-level authentication is enforced at the network edge or transport layer (e.g., requiring a valid client certificate), the attacker must possess valid transport credentials to initiate the stream and trigger the panic.

Impact

An attacker can cause a complete outage of the gRPC server by sending a request missing both :authority and Host headers, provided they can successfully establish a transport connection.

Patches

The issue has been addressed in master (and backported to 1.84.0, 1.83.2 and 1.82.2). The fix updates the HTTP/2 transport layer to reject requests missing both :authority and Host headers early, maintaining consistency with and other gRPC language implementations.

Severity

• CVSS Score: 8.7 / 10 (High)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

References

• https://github.com/grpc/grpc-go/security/advisories/GHSA-2v4p-qf9q-27wj
• https://nvd.nist.gov/vuln/detail/CVE-2026-84445
• https://github.com/grpc/grpc-go/issues/9354
• https://github.com/grpc/grpc-go/pull/9365
• https://github.com/grpc/grpc-go/pull/9366
• https://github.com/grpc/grpc-go/pull/9367
• https://github.com/grpc/grpc-go/commit/3822494d8ea03b992c089fd2a195f041762fffb7
• https://github.com/grpc/grpc-go/commit/8668b69c167df908b6b3666dcbf40992b9e932a4
• https://github.com/grpc/grpc-go/commit/93e31b48545e2a8aaeb6e06b47fb249f94e6297f
• https://github.com/grpc/grpc-go
• https://github.com/grpc/grpc-go/releases/tag/v1.82.2
• https://github.com/grpc/grpc-go/releases/tag/v1.83.2

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

---

Server panic via missing authority or Host headers in google.golang.org/grpc

CVE-2026-84445 / GHSA-2v4p-qf9q-27wj / GO-2026-6443

More information

Details

In google.golang.org/grpc, servers configured with xDS routing can panic when processing requests that lack both :authority and Host headers. The HTTP/2 transport layer accepted requests missing these headers, and the xDS server routing interceptor attempted to index the empty authority slice, causing an unhandled panic and terminating the server.

Severity

Unknown

References

• https://github.com/grpc/grpc-go/security/advisories/GHSA-2v4p-qf9q-27wj
• https://github.com/grpc/grpc-go/issues/9354
• https://github.com/grpc/grpc-go/pull/9365

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

---

Release Notes

grpc/grpc-go (google.golang.org/grpc)

v1.83.2: Release 1.83.2

Compare Source

Security

• server: Reject requests missing both :authority and Host headers with HTTP 400 and status Internal. (#​9365)
  • Special Thanks: @​winklemad

---

Configuration

📅 Schedule: (in timezone America/New_York)

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

👻 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 Mend Renovate CLI.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: ospk8s-renovate[bot]
Once this PR has been reviewed and has the lgtm label, please assign lpiwowar for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

• Configuration used: Central YAML (base), Organization UI (inherited)
• Review profile: CHILL
• Plan: Advanced
• Run ID: 3edf019e-d2c8-4545-9f64-0d20f3ffabe8

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

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

_{Comment @coderabbitai help to get the list of available commands.}

[openshift-ci]

Hi @ospk8s-renovate[bot]. Thanks for your PR.

I'm waiting for a openstack-k8s-operators member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[ospk8s-renovate]

ℹ️ Artifact update notice

File name: api/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):

• 3 additional dependencies were updated

Details:

Package	Change
golang.org/x/sys	v0.47.0 -> v0.48.0
golang.org/x/term	v0.45.0 -> v0.46.0
golang.org/x/text	v0.41.0 -> v0.42.0

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

• 5 additional dependencies were updated

Details:

Package	Change
golang.org/x/mod	v0.40.0 -> v0.41.0
golang.org/x/sync	v0.22.0 -> v0.23.0
golang.org/x/sys	v0.47.0 -> v0.48.0
golang.org/x/term	v0.45.0 -> v0.46.0
golang.org/x/text	v0.41.0 -> v0.42.0