HTTP/3 爆出严重漏洞：几百 KB 数据，就能让服务器卡死
内容提要
安全团队FoxIO披露HTTP/3“头部手风琴”拒绝服务攻击：QPACK请求头压缩在部分实现中未有效限制解码资源消耗，几百KB输入即可放大数千倍，导致内存耗尽、CPU死循环或崩溃。测试的10种实现中7种受影响，包括quic-go、Cloudflare quiche、lsquic、Bun、aioquic、h3和Wireshark。quic-go、quiche、lsquic、Wireshark已发布修复版本；Bun、h3、aioquic等披露时仍未修复。建议升级依赖，无法升级可暂时关闭HTTP/3。
延伸解读
漏洞根源：QPACK 解码资源限制失效
文章指出，问题集中在 HTTP/3 的请求头压缩技术 QPACK 上。部分实现只检查压缩后的大小，或等全部解压完才检查，甚至宣告了大小限制但代码未真正执行。这导致极小的传输数据在服务器端被放大为大量请求头对象，放大比例在特定测试路径中可达约 4000 倍。读者应理解，这是实现层面的资源消耗控制缺陷，而非 HTTP/3 协议本身必然不安全。
影响范围与修复状态需区分看待
FoxIO 测试的 10 种实现中 7 种受影响，包括 quic-go、Cloudflare quiche、lsquic、Bun、aioquic、h3 和 Wireshark。其中 quic-go、quiche、lsquic、Wireshark 已发布修复版本；Bun、h3、aioquic 在披露时仍未修复。Wireshark 的问题发生在协议解析过程，与网站服务器遭攻击的场景不同。读者应依据实际集成的依赖版本判断风险，并持续关注项目最新公告。
攻击后果因实现而异，不能混用测试数据
文章以 Bun 为例展示两种独立结果：约 5.8 MiB 传输数据使 2 GiB 容器因内存耗尽被 OOM 杀死；单条流约 516 KiB 数据触发缓冲区扩容整数溢出，导致 CPU 死循环。文章特别提醒，不能把“516 KiB”理解为直接耗尽 2 GiB 容器。不同实现后果包括内存耗尽、CPU 死循环和线程 panic，读者在评估自身风险时应避免简单套用单一数字。
实用应对：升级依赖或暂时关闭 HTTP/3
对于使用 HTTP/3 的部署，尤其是 Caddy、Traefik、LiteSpeed 或相关 QUIC 库，文章建议检查实际集成的依赖版本，并升级到已修复版本。若无法立即升级，可暂时关闭 HTTP/3 作为缓解措施。文章同时指出 HTTP/3 仍可继续使用，但需关注实现本身的安全更新，重点在于资源限制是否生效、检查是否及时以及应用最终保留了多少数据。
Q&A
HTTP/3 的“头部手风琴攻击”是什么？
“头部手风琴攻击”（Header Accordions）是一种针对 HTTP/3 的拒绝服务攻击。它利用 QPACK 请求头压缩机制，在部分实现中未有效限制解码资源消耗，导致几百 KB 的输入在服务器端放大数千倍，从而耗尽内存、CPU 死循环或崩溃。
为什么几百 KB 的数据就能让 HTTP/3 服务器卡死？
问题出在 QPACK 请求头压缩的解码过程。部分实现只检查压缩后的大小，或等全部解压完才检查，甚至宣告了限制但未执行。于是很小的传输数据在服务器端被展开成大量请求头对象，放大比例可达约 4000 倍，造成资源耗尽。
哪些 HTTP/3 实现受“头部手风琴攻击”影响？
FoxIO 测试了 10 种实现，其中 7 种受影响：quic-go、Cloudflare quiche、lsquic、Bun、aioquic/mitmproxy、h3（hyperium）和 Wireshark。后果包括内存耗尽、CPU 死循环和线程 panic。
Bun 在攻击下的具体表现是什么？
研究人员在 Bun 上展示了两种独立结果：约 5.8 MiB 传输数据导致 2 GiB 容器被 OOM 杀死；单条流约 516 KiB 传输数据触发缓冲区扩容整数溢出，程序进入死循环，CPU 持续占满。两者不能混为一谈。
哪些 HTTP/3 组件已经发布了修复版本？
截至 2026 年 10 月 20 日，已发布修复版本的组件包括：quic-go 0.57.0、Cloudflare quiche 0.29.3、lsquic 4.9.0、Wireshark 4.6.2 / 4.4.12。Bun 1.4.3、h3、aioquic/mitmproxy 在披露时仍未修复。
如果无法升级 HTTP/3 依赖，应该怎么办？
建议优先升级相关依赖到修复版本。如果无法升级，可以暂时关闭 HTTP/3 以规避风险，并持续关注项目的最新安全公告。
