写在前面2026年6月安全圈被一个编号为CVE-2026-49975的漏洞刷屏了。这个被称为“HTTP/2 Bomb”的远程拒绝服务漏洞以一种近乎“降维打击”的方式让全球超过88万个网站暴露在风险之中。更令人震撼的是这个漏洞竟是由 OpenAI 的 Codex AI 模型在分析公开代码库时发现的。一个在人类安全研究员眼皮底下存活了超过14年的协议设计缺陷被 AI 一眼看穿。本文将深入剖析 CVE-2026-49975 的技术原理重点分析它对Microsoft IIS 服务器的威胁并提供完整的检测、缓解与防御方案。一、漏洞全景HTTP/2 Bomb 到底是什么1.1 漏洞基本信息根据美国国家漏洞数据库NVD和奇安信威胁情报中心的通报CVE-2026-49975 的核心信息如下属性内容漏洞编号CVE-2026-49975漏洞别名HTTP/2 Bomb公开时间2026年6月2日CVSS 3.1 评分9.8高危/ 7.5高威胁类型拒绝服务DoS利用前提无需身份验证网络可达即可PoC 状态已公开在野利用未发现截至6月初影响范围覆盖了几乎所有主流 Web 服务器Microsoft IIS含 Windows Server 2025Nginx 1.29.8Apache HTTPDmod_http2 2.0.41含 2.4.17 ~ 2.4.67Envoy≤ 1.37.2Cloudflare Pingora≤ 0.8.01.2 攻击效果一台普通电脑20 秒拖垮服务器根据 Imperva 和 HAProxy 官方的测试数据一个攻击者使用普通家用电脑在 100 Mbps 的网络连接下可在 10~20 秒内让目标服务器分配并锁定高达 32GB 的内存导致服务器直接宕机。更可怕的是攻击者只需要建立单个 HTTP/2 连接不需要大流量、不需要僵尸网络。这意味着传统基于流量阈值或连接数阈量的 DDoS 防护手段完全失效。1.3 发现过程AI 挖掘出 14 年“盲点”这个漏洞的发现过程本身就是一个值得关注的故事。根据 Calif 公司 CEO Thai Duong 的博客披露Calif 团队使用 OpenAI 的 Codex AI 模型对多个公开代码库进行解析时AI 识别出两个已知技术可以串联成一条完整的攻击链。这两个技术分别是HPACK 压缩炸弹compression bomb—— 已公开近十年Slowloris 风格的流量控制停滞flow-control hold—— 同样已知多年人类安全研究员花了 14 年没能把这两者联系起来AI 做到了。这或许预示着安全行业的一个转折点AI 辅助漏洞挖掘正在从“辅助工具”走向“核心发现引擎”。二、技术深剖HPACK 压缩 流量控制 完美风暴要理解 CVE-2026-49975必须深入理解 HTTP/2 的两个核心机制HPACK 头压缩和流量控制Flow Control。2.1 HPACK 头压缩性能利器如何变成攻击武器2.1.1 HPACK 工作原理简述HTTP/2 于 2015 年由 IETF 正式发布。为了提升传输效率HTTP/2 引入了HPACK头部压缩算法。HPACK 的核心设计包含两个表静态表Static Table包含 61 个常见的 HTTP 头部字段如:method: GET、:path: /等所有连接共享不可修改。动态表Dynamic Table在会话过程中动态更新客户端和服务器各自维护一份。通信双方通过索引Index来引用表中已有的头部字段而不是每次都传输完整的字符串。例如一个 1 字节的索引引用可以代表一个完整的头部字段。这本是为了节省带宽的设计却成了漏洞的“放大器”。2.1.2 压缩炸弹的攻击手法根据 Calif 和 Imperva 的技术分析攻击者的操作分为几步第一步播种Seeding攻击者发送一个几乎为空的头部 payload但这个 payload 会被服务器放入 HPACK 动态表中。第二步索引引用轰炸Indexed Reference Bombing攻击者随后发送成千上万个 1 字节的索引引用每个引用都指向动态表中那个几乎为空的头部条目。关键点在于每个 1 字节的引用服务器都必须为其分配一个完整的内部数据结构书签记录、内存表条目等由于头部本身很小标准的“解码后头部大小限制”永远不会触发内存放大倍数高达 5,700:1“One byte on the wire becomes one full header allocation on the server, repeated thousands of times per request.”—— Calif CEO Thai Duong第三步Cookie 拆分绕过限制Apache/Envoy 特有对于实施了“最大头部数量”限制的服务器如 Apache 的LimitRequestFields攻击者还有一个变通手段将 Cookie 头部拆分成无数个独立的 Cookie 字段。Apache 和 Envoy 在合并 Cookie 字段时未能正确计数导致LimitRequestFields限制被绕过。2.2 流量控制停滞把内存“锁死”如果说 HPACK 压缩炸弹是“打开水龙头”那么流量控制停滞就是“堵住排水口”。2.2.1 HTTP/2 流量控制机制HTTP/2 的流量控制允许接收方通过WINDOW_UPDATE帧动态通告可用窗口大小。发送方只能在接收方通告的窗口范围内发送数据。这本是为了防止接收方被数据淹没的保护机制。2.2.2 攻击者的操作根据多个安全厂商的分析攻击者的操作是通告零字节的流量控制窗口WINDOW_UPDATEwith 0服务器无法发送响应数据因为窗口为 0连接一直处于“挂起”状态攻击者每隔几秒发送 1 字节的 WINDOW_UPDATE 帧重置发送超时计时器服务器永远无法释放之前为 HPACK 条目分配的内存这本质上是一种Slowloris 风格的攻击——用极低速率维持连接活跃让服务器资源永远无法回收。2.3 攻击链条完整示意┌─────────────────────────────────────────────────────────────────────┐ │ CVE-2026-49975 攻击链条 │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ ① 攻击者建立 HTTP/2 连接 │ │ ↓ │ │ ② 发送几乎为空的头部 → 服务器分配动态表条目播种 │ │ ↓ │ │ ③ 发送数千个 1 字节索引引用 → 服务器分配数千个内部数据结构 │ │ 内存放大 5,700:1但头部大小限制不触发 │ │ ↓ │ │ ④ 通告零字节流量控制窗口 → 服务器无法发送响应 │ │ ↓ │ │ ⑤ 定期发送 1 字节 WINDOW_UPDATE → 重置超时保持连接活跃 │ │ ↓ │ │ ⑥ 内存被锁定 → 无法释放 → 服务器 OOM → 拒绝服务 │ │ │ │ 结果20 秒内单客户端耗尽 32GB 服务器内存 │ └─────────────────────────────────────────────────────────────────────┘三、IIS 服务器处境最危险的玩家3.1 IIS 的尴尬位置在所有受影响的主流 Web 服务器中Microsoft IIS 的处境最为尴尬服务器修复状态修复版本Nginx✅ 已修复1.29.82025年4月Apache HTTPD✅ 已修复mod_http2 2.0.412026年5月Microsoft IIS❌ 未修复暂无补丁Envoy❌ 未修复暂无补丁Cloudflare Pingora❌ 未修复暂无补丁根据 cybersecurity-help.cz 的漏洞数据库截至 2026 年 6 月 8 日官方尚无针对 IIS 的解决方案。根据 Red Hat 的安全公告Apache 的 CVE-2026-49975 已被评定为Important级别。而 IIS 的官方补丁状态仍是“未知”。3.2 IIS 为何“中招”根据漏洞描述IIS 的漏洞存在于HTTP/2 请求处理和 HPACK 头部处理过程中当处理以下两种恶意请求时触发重复的索引头部引用repeated indexed header references停滞的流量控制窗口stalled flow-control window关键在于该问题在默认 HTTP/2 配置下即可被利用。也就是说只要 IIS 开启了 HTTP/2默认开启就存在风险。3.3 Windows Server 2025 也未能幸免根据多个安全公告的确认Windows Server 2025 自带的 IIS 同样受影响。这意味着即便是微软最新版本的服务器操作系统即便是默认配置、未做任何修改的 IIS同样可以被 HTTP/2 Bomb 一击击倒四、实战检测如何判断你的 IIS 是否中招4.1 自查清单在等待微软官方补丁的同时建议按照以下清单进行自查检查项操作预期结果HTTP/2 是否启用检查 IIS 站点绑定是否包含https且未禁用 HTTP/2如启用则存在风险内存使用趋势监控w3wp.exe进程内存如出现异常陡增则可能被攻击连接状态检查是否有大量长连接处于CLOSE_WAIT或挂起状态异常则需警惕日志分析检查 HTTP/2 相关错误日志查找异常请求模式4.2 监控脚本示例以下 PowerShell 脚本可用于监控 IIS 工作进程的内存使用情况# IIS 内存监控脚本# 建议每 5 分钟执行一次记录到日志$ThresholdMB 2048# 设置告警阈值2GB$ProcessNamew3wp$ProcessesGet-Process-Name$ProcessName-ErrorAction SilentlyContinueforeach($Procin$Processes){$MemoryMB[math]::Round($Proc.WorkingSet/1MB,2)$TimeStampGet-Date-Formatyyyy-MM-dd HH:mm:ssif($MemoryMB-gt$ThresholdMB){Write-Warning[$TimeStamp] WARNING:$($Proc.ProcessName)(PID:$($Proc.Id)) memory: ${MemoryMB}MB# 可在此触发告警通知}else{Write-Host[$TimeStamp] INFO:$($Proc.ProcessName)(PID:$($Proc.Id)) memory: ${MemoryMB}MB}}4.3 流量特征识别根据 Imperva 威胁研究团队的观察攻击初期的流量特征包括密集的小型头部块突发aggressive, dense bursts of small header blocks受限窗口下的持续连接connections under restricted windows without terminating自动化的探测行为automated probing behavior而非标准的应用层 payload这些特征可以帮助安全团队在 WAF 或网络层进行早期识别。五、缓解方案微软补丁出来前我们能做什么5.1 方案对比总览方案适用场景有效性副作用实施难度禁用 HTTP/2所有 IIS 部署⭐⭐⭐⭐⭐性能下降低前置反向代理有 HAProxy/Nginx 的环境⭐⭐⭐⭐⭐架构调整中内存限制cgroups容器化部署⭐⭐⭐可能 OOM-kill中WAF 规则有 WAF 的环境⭐⭐⭐⭐需更新规则低5.2 方案一禁用 HTTP/2最直接根据 Red Hat 的安全公告禁用 HTTP/2 是最直接有效的缓解措施。IIS 中禁用 HTTP/2 的方法打开IIS 管理器选择目标站点双击“绑定”编辑 HTTPS 绑定在“SSL 设置”中取消勾选“启用 HTTP/2”或者通过 PowerShell# 禁用特定站点的 HTTP/2# 注意需要 IIS 10.0 及以上版本Import-ModuleWebAdministration# 查看当前 HTTP/2 状态Get-WebConfigurationProperty-Filtersystem.webServer/httpProtocol-NameallowHttp2-LocationDefault Web Site# 禁用 HTTP/2Set-WebConfigurationProperty-Filtersystem.webServer/httpProtocol-NameallowHttp2-Value$false-LocationDefault Web Site# 重启 IISiisreset⚠️ 禁用 HTTP/2 的影响根据 Red Hat 的官方说明✅兼容性不受影响——所有现代浏览器和 API 客户端会自动回退到 HTTP/1.1⚠️页面加载速度下降——HTTP/1.1 顺序传输文件无法利用 HTTP/2 的多路复用⚠️带宽消耗增加——HTTP/1.1 传输未压缩的纯文本头部失去 HPACK 的数据节省⚠️TCP 连接数、CPU 和内存使用会上升建议如果业务对性能要求极高可以考虑仅在非关键业务时段禁用或采用方案二。5.3 方案二前置反向代理“虚拟补丁”HAProxy 官方明确表示如果在 Web 服务器前部署 HAProxy则已受到保护。HAProxy 之所以免疫是因为它作为协议终结者protocol terminator在边缘网络安全地处理客户端 HTTP/2 流量并以 HTTP/1.1 转发给后端服务器。后端 IIS 服务器根本不直接面对恶意 HTTP/2 请求。HAProxy 配置示例# haproxy.cfg - 前置 HAProxy 保护 IIS 后端 frontend http2_frontend bind :443 ssl crt /etc/ssl/certs/server.pem alpn h2,http/1.1 mode http # 限制请求头数量 - 针对 CVE-2026-49975 http-request deny if { hdr_cnt(cookie) gt 100 } # 限制单个连接上的流数量 http-request deny if { sc_http2_streams gt 100 } default_backend iis_backend backend iis_backend mode http server iis1 192.168.1.10:80 check # 以 HTTP/1.1 转发IIS 不直接面对 HTTP/2 攻击5.4 方案三Nginx 作为 TLS 终结代理如果你的环境已经使用 Nginx 作为反向代理那么好消息是Nginx 1.29.8 已经修复了此漏洞。Nginx 1.29.8 引入了max_headers指令默认限制为 1000 个请求头。# nginx.conf - 作为 IIS 的前置代理 http { # 限制请求头数量 - CVE-2026-49975 缓解 max_headers 1000; # 默认值可显式配置 # 限制头部大小 large_client_header_buffers 4 16k; server { listen 443 ssl http2; server_name your-domain.com; # 代理到后端 IIS location / { proxy_pass http://iis-backend:80; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; # 禁用后端 HTTP/2使用 HTTP/1.1 proxy_http_version 1.1; } } }5.5 方案四内存限制终极防线如果无法禁用 HTTP/2 也无法前置代理可以考虑为 IIS 工作进程设置严格的内存限制。在 Windows 环境中可以通过以下方式方法一IIS 应用程序池内存限制打开 IIS 管理器选择“应用程序池”右键目标池 →“高级设置”在“回收”部分设置“虚拟内存限制”如 2GB设置“专用内存限制”如 2GB方法二Job Object 限制更精细# 使用 PowerShell 为进程设置内存限制# 需要管理员权限$ProcessNamew3wp$MemoryLimitMB 2048# 获取所有 w3wp 进程$ProcsGet-Process-Name$ProcessNameforeach($Procin$Procs){# 使用 Set-Process 设置内存限制需要 Windows 10/Server 2016# 注意此操作需要安装相应的 PowerShell 模块try{Set-Process-Id$Proc.Id-MemoryLimit$MemoryLimitMB-ErrorAction StopWrite-HostSet memory limit for PID$($Proc.Id)to ${MemoryLimitMB}MB}catch{Write-WarningFailed to set memory limit for PID$($Proc.Id):$_}}⚠️注意内存限制可能导致工作进程被 OOM-kill需确保 IIS 的快速故障保护和进程回收机制已启用以便被 kill 的进程能自动重启。六、补丁追踪什么时候能等来微软的官方修复6.1 各厂商修复时间线时间事件2025年4月Nginx 1.29.8 悄然发布引入max_headers指令2026年5月下旬Apache 在 mod_http2 v2.0.41 中修复2026年6月2日CVE-2026-49975 公开披露2026年6月3日Calif 发布完整技术文档2026年6月4日各安全厂商发布公告PoC 公开待定Microsoft IIS 官方补丁6.2 关注渠道建议通过以下渠道追踪微软的补丁进展Microsoft Security Response CenterMSRC官方安全公告Microsoft Update Catalog补丁发布Windows Server 更新服务WSUS企业环境Microsoft TechCommunity IIS 板块6.3 3CX 的应急响应案例3CX 的应对策略值得参考漏洞披露后3CX 发现Debian Bookworm 和 Trixie 仓库中尚无打过补丁的 Nginx 版本。他们没有等待 Debian 维护者而是直接将 Nginx 嵌入到 3CX 的安装和更新流程中绕过操作系统包管理依赖在 48 小时内向客户推送了热修复。启示对于关键业务系统不应完全依赖操作系统发行版的补丁周期。建立自己的应急响应和热修复能力至关重要。七、深度思考为什么 HTTP/2 的设计缺陷能存活 14 年7.1 协议设计的“合理误用”困境CVE-2026-49975 之所以能存活如此之久根本原因在于攻击者利用的每一个步骤单独来看都是符合 HTTP/2 协议规范的合法行为。HPACK 索引引用是协议的标准功能流量控制窗口通告是协议的标准功能保持连接活跃也是协议的标准行为没有任何一个单独的操作是“违规”的。攻击链的威力来自这些合法操作的组合。这揭示了一个深刻的教训协议安全不能只审查单个功能是否合规还必须审查功能的组合效应。7.2 AI 漏洞挖掘的启示根据 CSO Online 的报道这个漏洞在14 年间经历了无数人类安全研究员的审查却始终未被发现。直到 Calif 使用OpenAI Codex进行辅助分析AI 模型解析了多个公开代码库识别出两个各自公开了近十年的技术可以被无缝串联成一条攻击链。这标志着安全行业的一个重要转折点维度传统人工审计AI 辅助审计代码覆盖率有限大规模并行跨项目关联依赖专家经验自动模式识别发现速度数月到数年数小时到数天组合攻击识别困难相对容易7.3 HTTP/3 能幸免吗HTTP/3 基于 QUIC 协议使用QPACK代替 HPACK 进行头部压缩。QPACK 在设计上确实修复了 HPACK 的一些已知问题但是否能完全避免此类组合攻击尚待时间检验。短期内不建议将“升级到 HTTP/3”作为 CVE-2026-49975 的解决方案——因为HTTP/3 的部署率远低于 HTTP/2QPACK 本身也可能存在尚未发现的组合漏洞大多数现有基础设施尚未支持 HTTP/3八、实践建议与趋势判断8.1 立即行动清单优先级排序优先级行动项负责团队P0确认所有面向公网的 IIS 服务器是否开启了 HTTP/2运维/安全P0对无法立即修补的服务器禁用 HTTP/2或前置代理运维P1部署内存监控设置告警阈值运维P1更新 WAF/IPS 规则Check Point、Imperva 等已发布规则安全P2关注微软官方补丁制定灰度发布计划运维/安全P2评估业务对 HTTP/2 的依赖程度制定长期协议策略架构8.2 长期架构建议分层防御不要将 Web 服务器直接暴露在公网。在前端部署反向代理HAProxy/Nginx/Envoy作为 TLS 终结层后端服务器仅接受 HTTP/1.1 流量。默认安全审查所有默认启用的协议功能。“默认开启”不等于“默认安全”。资源隔离为 Web 服务器工作进程设置严格的内存和连接数限制即使漏洞被利用也能将影响控制在单个进程范围内。AI 辅助安全审计将 AI 代码分析工具纳入安全开发生命周期SDL尤其是在协议实现和复杂状态机的审计中。8.3 趋势判断第一HTTP/2 协议层的漏洞不会到此为止。HPACK 和流量控制的组合攻击只是揭开了冰山一角。随着 AI 辅助漏洞挖掘的普及更多类似的“组合型”协议漏洞将被发现。第二“虚拟补丁”将成为新常态。对于 IIS、Envoy 等补丁滞后的平台前置 WAF/反向代理将成为事实上的标准防御手段。第三AI 在安全领域的角色正在从“辅助”转向“主导”。CVE-2026-49975 的发现过程证明AI 在识别跨组件、跨项目的组合攻击方面具有人类难以企及的优势。写在最后CVE-2026-49975 不仅是一个技术漏洞更是一面镜子。它照出了HTTP/2 协议设计中“合法功能组合”带来的安全隐患照出了传统人工安全审计的局限性也照出了AI 在安全领域的巨大潜力。对于 IIS 管理员来说现在能做的就是立刻行动——要么禁用 HTTP/2要么前置代理要么做好内存监控。等待微软补丁是被动的主动防御才是安全的。对于整个行业来说CVE-2026-49975 或许只是一个开始。在 AI 辅助漏洞挖掘的时代我们可能需要重新审视许多“已知安全”的协议和系统。安全没有终点只有不断演进的攻防博弈。参考资料Calif 官方博客blog.calif.io/p/codex-discovered-a-hidden-http2-bombImperva 安全公告2026年6月4日HAProxy 官方博客2026年6月5日Red Hat 安全公告 RHSB-2026-007奇安信威胁情报中心安全通告2026年6月4日NVDnvd.nist.gov/vuln/detail/CVE-2026-49975
CVE-2026-49975 漏洞分析：HTTP/2 HPACK 头压缩如何被利用耗尽 IIS 服务器资源？
发布时间：2026/6/26 7:57:24
写在前面2026年6月安全圈被一个编号为CVE-2026-49975的漏洞刷屏了。这个被称为“HTTP/2 Bomb”的远程拒绝服务漏洞以一种近乎“降维打击”的方式让全球超过88万个网站暴露在风险之中。更令人震撼的是这个漏洞竟是由 OpenAI 的 Codex AI 模型在分析公开代码库时发现的。一个在人类安全研究员眼皮底下存活了超过14年的协议设计缺陷被 AI 一眼看穿。本文将深入剖析 CVE-2026-49975 的技术原理重点分析它对Microsoft IIS 服务器的威胁并提供完整的检测、缓解与防御方案。一、漏洞全景HTTP/2 Bomb 到底是什么1.1 漏洞基本信息根据美国国家漏洞数据库NVD和奇安信威胁情报中心的通报CVE-2026-49975 的核心信息如下属性内容漏洞编号CVE-2026-49975漏洞别名HTTP/2 Bomb公开时间2026年6月2日CVSS 3.1 评分9.8高危/ 7.5高威胁类型拒绝服务DoS利用前提无需身份验证网络可达即可PoC 状态已公开在野利用未发现截至6月初影响范围覆盖了几乎所有主流 Web 服务器Microsoft IIS含 Windows Server 2025Nginx 1.29.8Apache HTTPDmod_http2 2.0.41含 2.4.17 ~ 2.4.67Envoy≤ 1.37.2Cloudflare Pingora≤ 0.8.01.2 攻击效果一台普通电脑20 秒拖垮服务器根据 Imperva 和 HAProxy 官方的测试数据一个攻击者使用普通家用电脑在 100 Mbps 的网络连接下可在 10~20 秒内让目标服务器分配并锁定高达 32GB 的内存导致服务器直接宕机。更可怕的是攻击者只需要建立单个 HTTP/2 连接不需要大流量、不需要僵尸网络。这意味着传统基于流量阈值或连接数阈量的 DDoS 防护手段完全失效。1.3 发现过程AI 挖掘出 14 年“盲点”这个漏洞的发现过程本身就是一个值得关注的故事。根据 Calif 公司 CEO Thai Duong 的博客披露Calif 团队使用 OpenAI 的 Codex AI 模型对多个公开代码库进行解析时AI 识别出两个已知技术可以串联成一条完整的攻击链。这两个技术分别是HPACK 压缩炸弹compression bomb—— 已公开近十年Slowloris 风格的流量控制停滞flow-control hold—— 同样已知多年人类安全研究员花了 14 年没能把这两者联系起来AI 做到了。这或许预示着安全行业的一个转折点AI 辅助漏洞挖掘正在从“辅助工具”走向“核心发现引擎”。二、技术深剖HPACK 压缩 流量控制 完美风暴要理解 CVE-2026-49975必须深入理解 HTTP/2 的两个核心机制HPACK 头压缩和流量控制Flow Control。2.1 HPACK 头压缩性能利器如何变成攻击武器2.1.1 HPACK 工作原理简述HTTP/2 于 2015 年由 IETF 正式发布。为了提升传输效率HTTP/2 引入了HPACK头部压缩算法。HPACK 的核心设计包含两个表静态表Static Table包含 61 个常见的 HTTP 头部字段如:method: GET、:path: /等所有连接共享不可修改。动态表Dynamic Table在会话过程中动态更新客户端和服务器各自维护一份。通信双方通过索引Index来引用表中已有的头部字段而不是每次都传输完整的字符串。例如一个 1 字节的索引引用可以代表一个完整的头部字段。这本是为了节省带宽的设计却成了漏洞的“放大器”。2.1.2 压缩炸弹的攻击手法根据 Calif 和 Imperva 的技术分析攻击者的操作分为几步第一步播种Seeding攻击者发送一个几乎为空的头部 payload但这个 payload 会被服务器放入 HPACK 动态表中。第二步索引引用轰炸Indexed Reference Bombing攻击者随后发送成千上万个 1 字节的索引引用每个引用都指向动态表中那个几乎为空的头部条目。关键点在于每个 1 字节的引用服务器都必须为其分配一个完整的内部数据结构书签记录、内存表条目等由于头部本身很小标准的“解码后头部大小限制”永远不会触发内存放大倍数高达 5,700:1“One byte on the wire becomes one full header allocation on the server, repeated thousands of times per request.”—— Calif CEO Thai Duong第三步Cookie 拆分绕过限制Apache/Envoy 特有对于实施了“最大头部数量”限制的服务器如 Apache 的LimitRequestFields攻击者还有一个变通手段将 Cookie 头部拆分成无数个独立的 Cookie 字段。Apache 和 Envoy 在合并 Cookie 字段时未能正确计数导致LimitRequestFields限制被绕过。2.2 流量控制停滞把内存“锁死”如果说 HPACK 压缩炸弹是“打开水龙头”那么流量控制停滞就是“堵住排水口”。2.2.1 HTTP/2 流量控制机制HTTP/2 的流量控制允许接收方通过WINDOW_UPDATE帧动态通告可用窗口大小。发送方只能在接收方通告的窗口范围内发送数据。这本是为了防止接收方被数据淹没的保护机制。2.2.2 攻击者的操作根据多个安全厂商的分析攻击者的操作是通告零字节的流量控制窗口WINDOW_UPDATEwith 0服务器无法发送响应数据因为窗口为 0连接一直处于“挂起”状态攻击者每隔几秒发送 1 字节的 WINDOW_UPDATE 帧重置发送超时计时器服务器永远无法释放之前为 HPACK 条目分配的内存这本质上是一种Slowloris 风格的攻击——用极低速率维持连接活跃让服务器资源永远无法回收。2.3 攻击链条完整示意┌─────────────────────────────────────────────────────────────────────┐ │ CVE-2026-49975 攻击链条 │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ ① 攻击者建立 HTTP/2 连接 │ │ ↓ │ │ ② 发送几乎为空的头部 → 服务器分配动态表条目播种 │ │ ↓ │ │ ③ 发送数千个 1 字节索引引用 → 服务器分配数千个内部数据结构 │ │ 内存放大 5,700:1但头部大小限制不触发 │ │ ↓ │ │ ④ 通告零字节流量控制窗口 → 服务器无法发送响应 │ │ ↓ │ │ ⑤ 定期发送 1 字节 WINDOW_UPDATE → 重置超时保持连接活跃 │ │ ↓ │ │ ⑥ 内存被锁定 → 无法释放 → 服务器 OOM → 拒绝服务 │ │ │ │ 结果20 秒内单客户端耗尽 32GB 服务器内存 │ └─────────────────────────────────────────────────────────────────────┘三、IIS 服务器处境最危险的玩家3.1 IIS 的尴尬位置在所有受影响的主流 Web 服务器中Microsoft IIS 的处境最为尴尬服务器修复状态修复版本Nginx✅ 已修复1.29.82025年4月Apache HTTPD✅ 已修复mod_http2 2.0.412026年5月Microsoft IIS❌ 未修复暂无补丁Envoy❌ 未修复暂无补丁Cloudflare Pingora❌ 未修复暂无补丁根据 cybersecurity-help.cz 的漏洞数据库截至 2026 年 6 月 8 日官方尚无针对 IIS 的解决方案。根据 Red Hat 的安全公告Apache 的 CVE-2026-49975 已被评定为Important级别。而 IIS 的官方补丁状态仍是“未知”。3.2 IIS 为何“中招”根据漏洞描述IIS 的漏洞存在于HTTP/2 请求处理和 HPACK 头部处理过程中当处理以下两种恶意请求时触发重复的索引头部引用repeated indexed header references停滞的流量控制窗口stalled flow-control window关键在于该问题在默认 HTTP/2 配置下即可被利用。也就是说只要 IIS 开启了 HTTP/2默认开启就存在风险。3.3 Windows Server 2025 也未能幸免根据多个安全公告的确认Windows Server 2025 自带的 IIS 同样受影响。这意味着即便是微软最新版本的服务器操作系统即便是默认配置、未做任何修改的 IIS同样可以被 HTTP/2 Bomb 一击击倒四、实战检测如何判断你的 IIS 是否中招4.1 自查清单在等待微软官方补丁的同时建议按照以下清单进行自查检查项操作预期结果HTTP/2 是否启用检查 IIS 站点绑定是否包含https且未禁用 HTTP/2如启用则存在风险内存使用趋势监控w3wp.exe进程内存如出现异常陡增则可能被攻击连接状态检查是否有大量长连接处于CLOSE_WAIT或挂起状态异常则需警惕日志分析检查 HTTP/2 相关错误日志查找异常请求模式4.2 监控脚本示例以下 PowerShell 脚本可用于监控 IIS 工作进程的内存使用情况# IIS 内存监控脚本# 建议每 5 分钟执行一次记录到日志$ThresholdMB 2048# 设置告警阈值2GB$ProcessNamew3wp$ProcessesGet-Process-Name$ProcessName-ErrorAction SilentlyContinueforeach($Procin$Processes){$MemoryMB[math]::Round($Proc.WorkingSet/1MB,2)$TimeStampGet-Date-Formatyyyy-MM-dd HH:mm:ssif($MemoryMB-gt$ThresholdMB){Write-Warning[$TimeStamp] WARNING:$($Proc.ProcessName)(PID:$($Proc.Id)) memory: ${MemoryMB}MB# 可在此触发告警通知}else{Write-Host[$TimeStamp] INFO:$($Proc.ProcessName)(PID:$($Proc.Id)) memory: ${MemoryMB}MB}}4.3 流量特征识别根据 Imperva 威胁研究团队的观察攻击初期的流量特征包括密集的小型头部块突发aggressive, dense bursts of small header blocks受限窗口下的持续连接connections under restricted windows without terminating自动化的探测行为automated probing behavior而非标准的应用层 payload这些特征可以帮助安全团队在 WAF 或网络层进行早期识别。五、缓解方案微软补丁出来前我们能做什么5.1 方案对比总览方案适用场景有效性副作用实施难度禁用 HTTP/2所有 IIS 部署⭐⭐⭐⭐⭐性能下降低前置反向代理有 HAProxy/Nginx 的环境⭐⭐⭐⭐⭐架构调整中内存限制cgroups容器化部署⭐⭐⭐可能 OOM-kill中WAF 规则有 WAF 的环境⭐⭐⭐⭐需更新规则低5.2 方案一禁用 HTTP/2最直接根据 Red Hat 的安全公告禁用 HTTP/2 是最直接有效的缓解措施。IIS 中禁用 HTTP/2 的方法打开IIS 管理器选择目标站点双击“绑定”编辑 HTTPS 绑定在“SSL 设置”中取消勾选“启用 HTTP/2”或者通过 PowerShell# 禁用特定站点的 HTTP/2# 注意需要 IIS 10.0 及以上版本Import-ModuleWebAdministration# 查看当前 HTTP/2 状态Get-WebConfigurationProperty-Filtersystem.webServer/httpProtocol-NameallowHttp2-LocationDefault Web Site# 禁用 HTTP/2Set-WebConfigurationProperty-Filtersystem.webServer/httpProtocol-NameallowHttp2-Value$false-LocationDefault Web Site# 重启 IISiisreset⚠️ 禁用 HTTP/2 的影响根据 Red Hat 的官方说明✅兼容性不受影响——所有现代浏览器和 API 客户端会自动回退到 HTTP/1.1⚠️页面加载速度下降——HTTP/1.1 顺序传输文件无法利用 HTTP/2 的多路复用⚠️带宽消耗增加——HTTP/1.1 传输未压缩的纯文本头部失去 HPACK 的数据节省⚠️TCP 连接数、CPU 和内存使用会上升建议如果业务对性能要求极高可以考虑仅在非关键业务时段禁用或采用方案二。5.3 方案二前置反向代理“虚拟补丁”HAProxy 官方明确表示如果在 Web 服务器前部署 HAProxy则已受到保护。HAProxy 之所以免疫是因为它作为协议终结者protocol terminator在边缘网络安全地处理客户端 HTTP/2 流量并以 HTTP/1.1 转发给后端服务器。后端 IIS 服务器根本不直接面对恶意 HTTP/2 请求。HAProxy 配置示例# haproxy.cfg - 前置 HAProxy 保护 IIS 后端 frontend http2_frontend bind :443 ssl crt /etc/ssl/certs/server.pem alpn h2,http/1.1 mode http # 限制请求头数量 - 针对 CVE-2026-49975 http-request deny if { hdr_cnt(cookie) gt 100 } # 限制单个连接上的流数量 http-request deny if { sc_http2_streams gt 100 } default_backend iis_backend backend iis_backend mode http server iis1 192.168.1.10:80 check # 以 HTTP/1.1 转发IIS 不直接面对 HTTP/2 攻击5.4 方案三Nginx 作为 TLS 终结代理如果你的环境已经使用 Nginx 作为反向代理那么好消息是Nginx 1.29.8 已经修复了此漏洞。Nginx 1.29.8 引入了max_headers指令默认限制为 1000 个请求头。# nginx.conf - 作为 IIS 的前置代理 http { # 限制请求头数量 - CVE-2026-49975 缓解 max_headers 1000; # 默认值可显式配置 # 限制头部大小 large_client_header_buffers 4 16k; server { listen 443 ssl http2; server_name your-domain.com; # 代理到后端 IIS location / { proxy_pass http://iis-backend:80; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; # 禁用后端 HTTP/2使用 HTTP/1.1 proxy_http_version 1.1; } } }5.5 方案四内存限制终极防线如果无法禁用 HTTP/2 也无法前置代理可以考虑为 IIS 工作进程设置严格的内存限制。在 Windows 环境中可以通过以下方式方法一IIS 应用程序池内存限制打开 IIS 管理器选择“应用程序池”右键目标池 →“高级设置”在“回收”部分设置“虚拟内存限制”如 2GB设置“专用内存限制”如 2GB方法二Job Object 限制更精细# 使用 PowerShell 为进程设置内存限制# 需要管理员权限$ProcessNamew3wp$MemoryLimitMB 2048# 获取所有 w3wp 进程$ProcsGet-Process-Name$ProcessNameforeach($Procin$Procs){# 使用 Set-Process 设置内存限制需要 Windows 10/Server 2016# 注意此操作需要安装相应的 PowerShell 模块try{Set-Process-Id$Proc.Id-MemoryLimit$MemoryLimitMB-ErrorAction StopWrite-HostSet memory limit for PID$($Proc.Id)to ${MemoryLimitMB}MB}catch{Write-WarningFailed to set memory limit for PID$($Proc.Id):$_}}⚠️注意内存限制可能导致工作进程被 OOM-kill需确保 IIS 的快速故障保护和进程回收机制已启用以便被 kill 的进程能自动重启。六、补丁追踪什么时候能等来微软的官方修复6.1 各厂商修复时间线时间事件2025年4月Nginx 1.29.8 悄然发布引入max_headers指令2026年5月下旬Apache 在 mod_http2 v2.0.41 中修复2026年6月2日CVE-2026-49975 公开披露2026年6月3日Calif 发布完整技术文档2026年6月4日各安全厂商发布公告PoC 公开待定Microsoft IIS 官方补丁6.2 关注渠道建议通过以下渠道追踪微软的补丁进展Microsoft Security Response CenterMSRC官方安全公告Microsoft Update Catalog补丁发布Windows Server 更新服务WSUS企业环境Microsoft TechCommunity IIS 板块6.3 3CX 的应急响应案例3CX 的应对策略值得参考漏洞披露后3CX 发现Debian Bookworm 和 Trixie 仓库中尚无打过补丁的 Nginx 版本。他们没有等待 Debian 维护者而是直接将 Nginx 嵌入到 3CX 的安装和更新流程中绕过操作系统包管理依赖在 48 小时内向客户推送了热修复。启示对于关键业务系统不应完全依赖操作系统发行版的补丁周期。建立自己的应急响应和热修复能力至关重要。七、深度思考为什么 HTTP/2 的设计缺陷能存活 14 年7.1 协议设计的“合理误用”困境CVE-2026-49975 之所以能存活如此之久根本原因在于攻击者利用的每一个步骤单独来看都是符合 HTTP/2 协议规范的合法行为。HPACK 索引引用是协议的标准功能流量控制窗口通告是协议的标准功能保持连接活跃也是协议的标准行为没有任何一个单独的操作是“违规”的。攻击链的威力来自这些合法操作的组合。这揭示了一个深刻的教训协议安全不能只审查单个功能是否合规还必须审查功能的组合效应。7.2 AI 漏洞挖掘的启示根据 CSO Online 的报道这个漏洞在14 年间经历了无数人类安全研究员的审查却始终未被发现。直到 Calif 使用OpenAI Codex进行辅助分析AI 模型解析了多个公开代码库识别出两个各自公开了近十年的技术可以被无缝串联成一条攻击链。这标志着安全行业的一个重要转折点维度传统人工审计AI 辅助审计代码覆盖率有限大规模并行跨项目关联依赖专家经验自动模式识别发现速度数月到数年数小时到数天组合攻击识别困难相对容易7.3 HTTP/3 能幸免吗HTTP/3 基于 QUIC 协议使用QPACK代替 HPACK 进行头部压缩。QPACK 在设计上确实修复了 HPACK 的一些已知问题但是否能完全避免此类组合攻击尚待时间检验。短期内不建议将“升级到 HTTP/3”作为 CVE-2026-49975 的解决方案——因为HTTP/3 的部署率远低于 HTTP/2QPACK 本身也可能存在尚未发现的组合漏洞大多数现有基础设施尚未支持 HTTP/3八、实践建议与趋势判断8.1 立即行动清单优先级排序优先级行动项负责团队P0确认所有面向公网的 IIS 服务器是否开启了 HTTP/2运维/安全P0对无法立即修补的服务器禁用 HTTP/2或前置代理运维P1部署内存监控设置告警阈值运维P1更新 WAF/IPS 规则Check Point、Imperva 等已发布规则安全P2关注微软官方补丁制定灰度发布计划运维/安全P2评估业务对 HTTP/2 的依赖程度制定长期协议策略架构8.2 长期架构建议分层防御不要将 Web 服务器直接暴露在公网。在前端部署反向代理HAProxy/Nginx/Envoy作为 TLS 终结层后端服务器仅接受 HTTP/1.1 流量。默认安全审查所有默认启用的协议功能。“默认开启”不等于“默认安全”。资源隔离为 Web 服务器工作进程设置严格的内存和连接数限制即使漏洞被利用也能将影响控制在单个进程范围内。AI 辅助安全审计将 AI 代码分析工具纳入安全开发生命周期SDL尤其是在协议实现和复杂状态机的审计中。8.3 趋势判断第一HTTP/2 协议层的漏洞不会到此为止。HPACK 和流量控制的组合攻击只是揭开了冰山一角。随着 AI 辅助漏洞挖掘的普及更多类似的“组合型”协议漏洞将被发现。第二“虚拟补丁”将成为新常态。对于 IIS、Envoy 等补丁滞后的平台前置 WAF/反向代理将成为事实上的标准防御手段。第三AI 在安全领域的角色正在从“辅助”转向“主导”。CVE-2026-49975 的发现过程证明AI 在识别跨组件、跨项目的组合攻击方面具有人类难以企及的优势。写在最后CVE-2026-49975 不仅是一个技术漏洞更是一面镜子。它照出了HTTP/2 协议设计中“合法功能组合”带来的安全隐患照出了传统人工安全审计的局限性也照出了AI 在安全领域的巨大潜力。对于 IIS 管理员来说现在能做的就是立刻行动——要么禁用 HTTP/2要么前置代理要么做好内存监控。等待微软补丁是被动的主动防御才是安全的。对于整个行业来说CVE-2026-49975 或许只是一个开始。在 AI 辅助漏洞挖掘的时代我们可能需要重新审视许多“已知安全”的协议和系统。安全没有终点只有不断演进的攻防博弈。参考资料Calif 官方博客blog.calif.io/p/codex-discovered-a-hidden-http2-bombImperva 安全公告2026年6月4日HAProxy 官方博客2026年6月5日Red Hat 安全公告 RHSB-2026-007奇安信威胁情报中心安全通告2026年6月4日NVDnvd.nist.gov/vuln/detail/CVE-2026-49975
