golang.org/x/net v0.60.0 修复 5 个 HTTP/2 问题：Trailer 内存放大、窗口变更 CPU 放大、flow control 重复退还与 HPACK 竞态
golang.org/x/net v0.60.0 于 2026-10-08 公布，修复以下 HTTP/2 安全问题。
1. Trailer 头导致 HTTP/2 server 内存耗尽
CVE-2026-78659，Go issue go.dev/issue/81857
客户端发送 Trailer 头时，HTTP server 会用头里的值填充传给 handler 的 Request.Trailer map。Request.Trailer 是 map，每个条目都占内存开销。对 HTTP/2 server，恶意客户端可发一个声明大量字段的 Trailer 头，使 server 分配不成比例的内存，同时绕过 Server.MaxHeaderValueCount 和 Server.MaxHeaderBytes 限制。
对 HTTP/1 server 不适用：HTTP/1 不支持在一个 TCP 连接上多路复用大量请求，且其 Server.MaxHeaderBytes 算法不同。
修复：Server.MaxHeaderValueCount 和 Server.MaxHeaderBytes 限制现在也作用于 Trailer 头里声明的 trailer 字段。
报告者 RyotaK（GMO Flatt Security Inc.）。
2. 反复变更 initial window 造成 CPU 消耗过高
CVE-2026-78669，Go issue go.dev/issue/81742
恶意 HTTP/2 对端可先开大量 stream，再发很多小的 SETTINGS 帧、内含 SETTINGS_INITIAL_WINDOW_SIZE 值，使 client 或 server 消耗过多 CPU。
修复：HTTP/2 client 与 server 现在高效处理 initial window size 变更（O(1) 而非 O(stream 数)）。
报告者 Jakub Ciolek。
3. HTTP/2 server stream 上 flow control 重复退还
CVE-2026-78663，Go issue go.dev/issue/81743
HTTP/2 server 可能对同一份数据把连接级 flow control 退两次：一次在客户端 reset stream 时（退还 stream 中已发送但未读部分），又一次在请求 handler 读取缓冲数据时。恶意客户端可利用它绕过配置的连接级 flow control 上限（MaxReceiveBufferPerConnection）。总缓冲数据仍受并发 stream 上限与 stream 级 flow control 限制。
修复：HTTP/2 server 现在对已 reset 的 stream，等到请求 handler 完成后再退还连接级 flow control。
报告者 Ali Sherif。
4. HPACK encoder 竞态导致 HTTP/2 server 崩溃
CVE-2026-97032，Go issue go.dev/issue/81867
HTTP/2 server 可能因并发修改 HPACK encoder 而崩溃：两个 goroutine 无同步地改 server 的 HPACK encoder——一个用它编码发往客户端的 HEADERS 帧，另一个在处理带 SETTINGS_HEADER_TABLE_SIZE 的 SETTINGS 帧时修改 encoder 的表大小。恶意客户端可反复发请求并改变 header table size 来把 server 打崩。
修复：不再立即应用 SETTINGS_HEADER_TABLE_SIZE，而是先缓冲收到的值，仅在 server 下次写帧之前应用。
报告者 RyotaK（GMO Flatt Security Inc.）。
另：畸形 framing 相关头
CVE-2026-78660 / GO-2026-6610，HTTP/2 transport 接受畸形 framing 相关头：历史上对畸形 framing 相关头较宽松，导致作为反向代理时可能把含此类头的响应转发给 HTTP/1 客户端，若 HTTP/1 客户端也不够严格，可能造成 response smuggling。
升级
运行依赖 x/net 的 HTTP/2 server 或 client 应升级到 v0.60.0。