# HTTP/3 爆出严重漏洞：几百 KB 数据，就能让服务器卡死 **URL:** \ **Category:** 安全情报\ **Created:** [2026 年10 月 22 日 07:47 UTC](https://meta.appinn.net/t/topic/94176 "2026-10-22T07:47:31Z")\ **Posts on this page:** 2\ **Page:** 1
作者： ![Qingwa](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/qingwa/32/58632_2.png) [@Qingwa](https://meta.appinn.net/u/Qingwa)\ 发布日期： [2026 年10 月 22 日 07:47 UTC](https://meta.appinn.net/t/topic/94176/1 "2026-10-22T07:47:31Z")
原始链接在： [HTTP/3 爆出严重漏洞：几百 KB 数据，就能让服务器卡死 - 小众软件](https://www.appinn.com/http3-header-accordions/) HTTP/3 也出事了。 安全研究团队 FoxIO 在 10 月 20 日公开了一类名为 **Header Accordions（头部手风琴攻击）** 的拒绝服务攻击。部分 HTTP/3 实现处理请求头时，几百 KB 的输入就可能换来远超这个量级的资源消耗。 研究人员测试 Bun 的 HTTP/3 服务时，发送了约 **516 KiB** 数据，服务器就陷入了死循环，CPU 占用率一直维持在 100%，新请求也处理不了了。 ![](https://h2cdn.appinn.me/original/3X/5/5/55f4d91c45626a962ed7f8cce1abbf51bdfe4c41.jpeg) ## 10 种实现，7 种发现问题 FoxIO 测试了 10 种 HTTP/3 相关实现，其中 7 种存在不同程度的问题： - **quic-go** ：Caddy、Traefik 等项目使用的 QUIC 实现。 - **Cloudflare quiche** ：Cloudflare 开发的 QUIC/HTTP/3 库。 - **lsquic** ：LiteSpeed 相关的 QUIC 实现。 - **Bun** ：JavaScript 运行时，其 HTTP/3 支持基于 lsquic。 - **aioquic / mitmproxy** ：Python QUIC 库，以及使用它的代理工具。 - **h3（hyperium）** ：Rust HTTP/3 库。 - **Wireshark** ：HTTP/3 协议解析器，处理特制流量时可能卡住或崩溃。 Wireshark 已经算在这 7 种里面；它的问题发生在协议解析过程，与网站服务器遭到攻击的场景有所区别。各实现的后果也不完全相同，包括内存耗尽、CPU 死循环和线程 panic。 ## 几百 KB，为什么能搞垮服务器？ 问题主要出在 HTTP/3 的请求头压缩技术 **QPACK** 上。 为了节省流量，重复出现的请求头可以用很短的索引表示。服务器收到后，再把索引还原成完整字段。这本来是正常的压缩机制，但部分实现没有在解码过程中有效限制资源消耗。 有的只检查压缩后的大小，有的等全部解压完才检查，还有的虽然宣告了大小限制，代码却没有真正执行。 于是，网络上传来的一小段数据，到了服务器里，就可能变成一大堆需要分配、复制和保留的请求头对象。 这也是 Header Accordions 这个名字的由来：传输时像收拢的手风琴，占不了多少空间；到了服务器上，却一下展开了。 在部分动态表引用测试中，每个很短的索引都会触发对较大字段的重新分配和复制，放大比例可达约 **4000 倍** 。这个比例来自特定测试路径，并非所有实现的共同表现。 ![](https://h2cdn.appinn.me/original/3X/9/9/99e22e166e5442dcb578103519a9ce3c167741a6.avif) 研究人员在 Bun 上展示了两种不同的结果： - **内存耗尽** ：约 5.8 MiB 的传输数据，让一个 2 GiB 容器被 OOM 杀死。 - **CPU 死循环** ：单条流约 516 KiB 的传输数据，触发缓冲区扩容时的整数溢出，程序进入死循环，CPU 持续占满。 这是两项独立测试，不能把“516 KiB”理解为“直接耗尽一个 2 GiB 容器”。 对于攻击者来说，麻烦之处就在于：在这些存在问题的配置下，并不需要很大的攻击流量，就可能让服务停止响应。[FoxIO 原始研究](https://foxio.io/blog/header-accordions-qpack-amplification-attacks-against-http-3-servers?utm_source=appinn.com) ## 哪些服务器需要注意？ 如果你使用了 HTTP/3，尤其是 Caddy、Traefik、LiteSpeed 或相关 QUIC 库，建议检查实际集成的依赖版本。 FoxIO 列出的修复版本如下， **统计截止日为 2026 年 10 月 20 日** ： | 组件 | 修复版本 | | --- | --- | | quic-go | 0.57.0 | | Cloudflare quiche | 0.29.3 | | lsquic | 4.9.0 | | Wireshark | 4.6.2 / 4.4.12 | 其中，quic-go、Cloudflare quiche 和 Wireshark 的修复版本，也可在各自的官方安全公告中核对：[quic-go 公告](https://github.com/quic-go/quic-go/security/advisories/GHSA-g754-hx8w-x2g6)、[quiche 公告](https://github.com/cloudflare/quiche/security/advisories/GHSA-4fgf-9xrr-88gf)、[Wireshark 公告](https://www.wireshark.org/security/wnpa-sec-2025-07.html)。 按照 FoxIO 在 10 月 20 日发布的状态，Bun 1.4.3、h3、aioquic / mitmproxy 仍有相关问题未修复。这是披露时的状态，部署前应继续查看项目的最新公告。 ## HTTP/3 还能放心用吗？ 可以继续用，但得关注实现本身的安全更新。 HTTP/3 基于 QUIC，使用 UDP 传输。这次研究集中暴露的是软件实现对请求头资源消耗的处理问题：限制有没有生效，检查得是否及时，以及应用最终保留了多少数据。 青小蛙觉得，对于很多小水管服务器来说，攻击者只需要一点点的流量，就需要服务器端几千倍的资源开销，完全是放大器效果，中招以后有些棘手。 能更新就更新，不能就先把 HTTP/3 关了？ ---
作者： ![tjsky](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/tjsky/32/31059_2.png) [@tjsky](https://meta.appinn.net/u/tjsky)\ 发布日期： [2026 年10 月 22 日 08:13 UTC](https://meta.appinn.net/t/topic/94176/2 "2026-10-22T08:13:22Z")
诶，我就直接不开HTTP3「只要没有弱点，就无法被攻击」