fix(security/unknown/examples/grpc_server): update module golang.org/x/net to v0.60.0 [security] (v1.x)

[renovate-sh-app]

This PR contains the following updates:

Package	Change	Age	Confidence
golang.org/x/net	v0.58.0 → v0.60.0

---

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

---

Configuration

📅 Schedule: (UTC)

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

🚦 Automerge: Enabled.

♻ 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

---

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.

[renovate-sh-app]

ℹ️ Artifact update notice

File name: examples/grpc_server/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
• The go directive was updated for compatibility reasons

Details:

Package	Change
go	1.25.0 -> 1.26.0
golang.org/x/sys	v0.47.0 -> v0.48.0
golang.org/x/text	v0.41.0 -> v0.42.0
google.golang.org/genproto/googleapis/rpc	v0.0.0-20260526163538-3dc84a4a5aaa -> v0.0.0-20260803160001-6ac0973c030d