一、引言当“快速重置”遇上“压缩炸弹”2023年10月HTTP/2 Rapid Reset攻击CVE-2023-44487的披露让整个Web安全社区为之一震。一个单连接、低成本的攻击手法竟能让全球最成熟的HTTP/2服务器陷入资源耗尽的困境。然而就在业界以为已经通过补丁和配置调优将这一威胁控制住的时候2026年6月一个被命名为“HTTP/2 Bomb”的新漏洞CVE-2026-49975横空出世。更令人警惕的是这两个漏洞并非孤立存在。根据安全厂商Calif的披露CVE-2026-49975是由研究人员使用OpenAI的Codex分析多个公开代码库后发现的——AI模型识别出两个各自存在近十年的已知技术可以无缝串联形成一条全新的攻击链。这条攻击链不仅继承了CVE-2023-44487的“快速重置”思路更在此基础上叠加了HPACK压缩炸弹和流控停滞技术将攻击威力提升到了新的量级。对于使用Microsoft IIS的运维团队来说形势尤为严峻截至本文撰写时2026年6月27日IIS仍然没有官方补丁。本文将深入剖析这两个漏洞的技术关联、在IIS中的具体表现以及当前可行的缓解方案。本文所有技术信息均基于2026年6月公开的安全公告、厂商披露和社区讨论确保内容的真实性和时效性。二、CVE-2023-44487HTTP/2 Rapid Reset 攻击回顾2.1 漏洞本质协议设计层面的“不对称战争”HTTP/2协议引入的多路复用Multiplexing机制允许在单个TCP连接上并发处理多个请求流Stream。每个流可以通过RST_STREAM帧独立取消这本是提升效率的设计。然而CVE-2023-44487正是利用了这种“低成本取消”与“高成本处理”之间的不对称性。攻击流程极为简洁客户端在单个HTTP/2连接上快速打开大量流每个流发送请求后立即发送RST_STREAM帧取消该流服务器在收到取消帧之前已经为每个流分配了内存、CPU等资源重复此过程服务器资源被迅速耗尽根据Red Hat的公告这种攻击可以在不依赖大量僵尸网络的情况下由少量客户端发起大规模DDoS攻击。CISA已将CVE-2023-44487列入已知被利用漏洞目录KEV说明该漏洞在2023年8月至10月期间已有在野利用。2.2 影响范围与修复CVE-2023-44487影响所有实现了HTTP/2协议的服务器和代理包括但不限于NginxApache HTTP ServerMicrosoft IISEnvoy各类云服务商的HTTP/2 termination点Microsoft的响应根据微软2023年的官方声明该攻击影响所有互联网暴露的HTTP/2端点微软已为IIS、.NET Kestrel和Windows本身构建了缓解措施。具体而言微软通过安全更新在HTTP.sys和Kestrel中增加了重置速率跟踪和激进连接关闭逻辑。关键配置对于仍在使用未打补丁版本的IIS管理员微软建议通过注册表禁用HTTP/2并回退到HTTP/1.1。注册表路径根据微软推荐HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters新建DWORD值EnableHttp2Tls和EnableHttp2Cleartext设置为0三、CVE-2026-49975HTTP/2 Bomb 深度剖析3.1 发现过程AI“发现”的0-day2026年6月2日安全厂商Calif通过公开邮件列表披露了HTTP/2 Bomb漏洞。这个漏洞的发现过程本身就极具故事性研究人员使用OpenAI的Codex分析多个公开代码库AI模型识别出两个独立的技术各自已存在近十年部分已被修复可以串联成一条全新的攻击链。Quang Luong发现了该漏洞Jun Rong和Duc Phan确认了在其他Web服务器上的攻击效果。漏洞披露时间线如下日期事件2026年4月向Nginx披露次日Nginx 1.29.8发布修复2026年5月27日向Apache披露同日修复并分配CVE-2026-499752026年6月2日公开披露确认IIS、Envoy、Pingora同样存在漏洞2026年6月3日Envoy发布补丁CVE-2026-47774根据披露信息该漏洞影响超过88万个支持HTTP/2且运行默认配置的网站。3.2 攻击链拆解三阶段“组合拳”CVE-2026-49975并非单一漏洞而是一条由三个已知技术串联而成的攻击链。第一阶段HPACK压缩炸弹Bookkeeping Compression BombHTTP/2使用HPACK算法压缩请求头维护一个动态表来存储重复出现的头部字段。攻击者利用这一机制向服务器动态表中填充一个几乎为空的头部然后发送数千个1字节的索引引用指向该头部每个1字节引用迫使服务器创建全新的逐条目簿记分配服务器虽然设置了“解码后大小限制”但由于头部本身几乎为空限制永远不会触发关键数据根据Calif的测试这种攻击可实现高达5,700:1的内存放大——即1字节的网络输入最终在服务器端消耗5,700字节的内存。对于Apache和Envoy攻击者还找到了绕过头部字段数量限制的方法将Cookie头拆分为多个独立的“碎屑”Crumbs而服务器未能正确计数。第二阶段流控停滞Flow-Control Slowloris Hold第一阶段已经让服务器分配了大量内存第二阶段的任务是让这些内存永远无法释放攻击者通告一个零字节的流控窗口zero-byte flow-control window这阻止了服务器发送响应攻击者以1字节为单位发送WINDOW_UPDATE帧来重置发送超时连接保持活跃已分配的内存被无限期“钉住”第三阶段多流叠加Multi-Stream Amplification攻击者在单个连接上打开数百个流每个流都执行上述操作。根据WindowsNews.ai的分析在默认的Nginx配置128个并发流下单个TCP握手即可消耗数百MB内存。在Apache或Envoy上单个客户端可在20秒内消耗并持有32GB服务器内存将后端机器推入swap并杀死系统性能。3.3 为什么传统防御无效传统防御手段为何无效解码后大小限制头部几乎为空“几乎没什么可解码”头部数量限制Cookie碎屑绕过计数单连接限速单连接即可造成巨大破坏IP黑名单攻击流量看起来是完全合法的HTTP/2帧核心问题“最大解码后头部大小”和“最大头部数量”是两种不同的限制服务器两者都需要。四、关联分析CVE-2026-49975 与 CVE-2023-44487 的技术血缘4.1 共同的“基因”HTTP/2流管理两个漏洞都根植于HTTP/2协议的核心机制——流Stream管理。CVE-2023-44487利用了RST_STREAM的快速取消能力让服务器为每个被立即取消的流付出处理成本。而CVE-2026-49975则将这一思路推向极致不仅创建大量流还让每个流保持存活并持有内存形成“僵尸流”。可以这样理解两者的关系CVE-2023-44487 快速创建 快速销毁让服务器疲于奔命CVE-2026-49975 快速创建 内存放大 永不销毁让服务器内存爆仓4.2 在IIS中的“变种”表现CVE-2026-49975在IIS中的具体表现根据Cybersecurity Help的漏洞描述漏洞存在于HTTP/2请求处理和HPACK头部处理中当处理使用重复索引头部引用和停滞流控窗口的构造HTTP/2请求时会发生不受控制的资源消耗。这与CVE-2023-44487在IIS中的表现形成了有趣的对比维度CVE-2023-44487IISCVE-2026-49975IIS攻击向量RST_STREAM快速取消HPACK索引引用 零窗口资源消耗类型CPU 线程池内存RAM单连接威力中耗尽线程高耗尽GB级内存缓解难度中有官方补丁高暂无补丁关键洞察CVE-2023-44487的补丁主要关注RST_STREAM的速率限制但并未解决HPACK索引引用和流控窗口组合造成的内存放大问题。这正是CVE-2026-49975能够“绕过”已有防护的原因——它利用了补丁未曾覆盖的攻击面。4.3 一个值得注意的细节CVE编号的“归属”在公开追踪中CVE-2026-49975紧密关联Apache侧的HTTP/2 Bomb问题特别是mod_http2中的Cookie头计数问题。然而并非所有HTTP/2 Bomb行为都等于CVE-2026-49975。Envoy发布了独立的公告追踪为CVE-2026-47774修复版本为1.35.11、1.36.7、1.37.3和1.38.1。Istio的安全公告也引用了CVE-2026-47774描述为“通过Cookie头HPACK放大导致HTTP/2内存耗尽”。这对IIS管理员意味着什么意味着不能简单地等待一个“CVE-2026-49975补丁”——微软可能会以独立的CVE编号或安全公告来处理IIS的修复。截至2026年6月27日微软官方尚未发布任何针对此漏洞的公告或补丁。五、影响评估谁最危险5.1 受影响产品清单根据SecLists邮件列表和多个安全厂商的公告以下产品的默认HTTP/2配置存在漏洞产品修复状态修复版本Nginx✅ 已修复1.29.8max_headers指令默认1000Apache HTTP Server✅ 已修复mod_http2 v2.0.41Microsoft IIS❌暂无补丁所有版本Envoy✅ 已修复1.35.11 / 1.36.7 / 1.37.3 / 1.38.1CVE-2026-47774Cloudflare Pingora❌ 暂无补丁所有版本5.2 IIS用户的“三不管”困境IIS用户面临一个尴尬的局面CVE-2023-44487的补丁微软已发布但不覆盖CVE-2026-49975的攻击向量CVE-2026-49975的补丁微软尚未发布且没有明确的时间表临时缓解方案需要禁用HTTP/2或依赖第三方前端防护根据SOC Prime的报道该攻击可以从一台100 Mbps连接的家用电脑发起并在数秒内让受影响服务器离线。Imperva的博客也确认了这一点单客户端20秒内可耗尽32GB服务器内存。5.3 真实世界影响虽然目前尚未有大规模在野利用的公开报告但风险正在迅速累积PoC代码已公开修复提交commit diffs本身就是公开的“任何有能力的AI模型都可以将这些差异转化为可工作的exploit”扫描活动已出现Imperva威胁研究团队在公开披露后已检测到针对性的探测和PoC验证活动攻击门槛极低不需要特殊头部或畸形帧只需要标准的TLS握手和HTTP/2连接前言六、缓解方案IIS管理员现在能做什么6.1 方案一禁用HTTP/2最直接但代价最大如果您的IIS服务器不需要HTTP/2这是最彻底的缓解方案。通过注册表禁用根据微软推荐# 以管理员身份运行reg addHKLM\System\CurrentControlSet\Services\HTTP\Parameters/v EnableHttp2Tls/t REG_DWORD/d 0/f reg addHKLM\System\CurrentControlSet\Services\HTTP\Parameters/v EnableHttp2Cleartext/t REG_DWORD/d 0/f# 重启HTTP服务或重启服务器net stop http/y netstarthttp通过应用程序池配置适用于IIS 10在应用程序池的高级设置中将“启用HTTP/2”设置为False⚠️注意禁用HTTP/2会导致性能下降特别是对于需要多路复用和头部压缩的场景。建议在非高峰时段执行此操作并充分测试。6.2 方案二前端部署代理/WAF推荐根据多个安全厂商的建议在前端部署能够强制限制请求头数量的代理或防火墙是目前最实际的缓解方案。HAProxy方案HAProxy官方博客明确指出HAProxy由于其严格的内存约束架构上对CVE-2026-49975具有天然免疫力。通过配置HAProxy的stick tables可以追踪异常的协议行为包括快速重置和畸形continuation帧并在恶意连接到达后端之前将其拒绝。HAProxy配置示例基于HAProxy官方推荐# 限制每个连接的并发流数量 http2-max-concurrent-streams 100 # 限制请求头数量 http-request deny if { req.hdr_count(X-*) gt 50 } # 使用stick table追踪异常行为 stick-table type ip size 1m expire 5m store http_req_rate(10s) http-request track-sc0 src http-request deny if { sc_http_req_rate(0) gt 100 }Imperva方案Imperva已确认其WAF客户完全受到保护不受CVE-2026-49975 exploitation尝试的影响。Check Point也在其IPS中增加了针对该漏洞的保护。Cloudflare方案虽然Cloudflare的Pingora自身存在漏洞但Cloudflare的CDN/WAF服务可以吸收或限速此类攻击。6.3 方案三服务器层资源限制临时缓解不彻底如果无法禁用HTTP/2也无法部署前端代理可以考虑在服务器层面设置资源限制Windows Server资源限制使用Job Objects或Windows System Resource Manager限制IIS工作进程的内存使用配置应用程序池回收策略设置私有内存限制达到阈值后自动回收IIS配置调整部分缓解降低maxConcurrentStreams如果可配置缩短连接超时时间启用快速失败保护Rapid Fail Protection⚠️重要提醒这些措施只能缓解而非根治。攻击者仍然可以在单次回收周期内造成拒绝服务。6.4 方案四监控与检测在补丁到来之前主动监控是必不可少的防线关键监控指标HTTP/2连接的内存使用量突增单连接上的流数量异常服务器内存使用率快速攀升应用程序池频繁回收PowerShell监控脚本示例# 监控IIS工作进程内存Get-Process-Name w3wp|Select-ObjectName,WorkingSet,PeakWorkingSet|Where-Object{$_.WorkingSet-gt1GB}# 监控HTTP.sys连接状态netsh http show servicestate|Select-StringHTTP/26.5 各方案对比方案有效性实施难度性能影响推荐度禁用HTTP/2⭐⭐⭐⭐⭐⭐⭐⭐性能下降紧急情况前端部署HAProxy⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐WAF/CDN防护⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐服务器资源限制⭐⭐⭐⭐⭐⭐⭐⭐纯监控⭐⭐⭐⭐⭐⭐⭐⭐七、与竞品对比各厂商的应对速度CVE-2026-49975的披露和修复过程为我们提供了一个观察各厂商安全响应能力的绝佳窗口厂商通知时间修复时间响应速度备注Nginx2026年4月次日⭐⭐⭐⭐⭐从freenginx导入max_headers指令Apache2026年5月27日当日⭐⭐⭐⭐⭐Stefan Eissing当日修复Envoy2026年6月2日2026年6月3日⭐⭐⭐⭐独立CVE-2026-47774Microsoft2026年6月2日未定⭐截至6月27日无公告值得深思的是Nginx在4月就已修复并发布了1.29.8Apache在5月27日当天修复而微软至今沉默。考虑到IIS在全球Web服务器市场的份额这种延迟令人担忧。LiteSpeed的“例外”值得一提的是LiteSpeed官方宣称其客户不受此漏洞影响这可能是因为其HTTP/2实现采用了不同的内存管理策略。八、架构设计启示HTTP/2实现的“隐性成本”CVE-2026-49975的深层启示在于协议层面的“效率设计”可能成为安全层面的“漏洞温床”。8.1 HPACK的“双刃剑”效应HPACK通过动态表和索引引用大幅提升了头部压缩效率但这种效率建立在服务器需要维护每个连接的状态表的基础上。当攻击者能够操纵这个状态表的填充方式时效率工具就变成了攻击武器。架构教训状态必须有边界任何需要维护每个连接状态的协议特性都必须有严格的上限“空”不等于“无害”传统安全思维关注“大”数据包但CVE-2026-49975证明了“小”数据包同样危险计数 ≠ 大小头部数量限制和头部大小限制是互补的缺一不可8.2 流控的“停滞”风险HTTP/2的流控机制允许接收方通过WINDOW_UPDATE控制发送方的数据速率。这本是防止发送方淹没接收方的保护机制但当攻击者利用它来“钉住”服务器内存时保护机制就成了攻击媒介。架构教训流必须有最大生命周期任何流都不应无限期存在无论窗口状态如何资源必须有回收机制即使连接保持活跃已完成的流所占用的内存也应被及时释放8.3 对IIS架构的反思IIS的HTTP/2实现在HTTP.sys内核驱动中这种内核级实现既有优势也有劣势优势高性能低延迟与Windows网络栈深度集成劣势修复需要操作系统级更新发布周期长内核级漏洞的修复更加谨慎测试要求更高无法像用户态软件那样快速迭代这解释了为什么Nginx和Apache能在数天内修复而IIS需要更长时间。但从4月到6月底近3个月的窗口期仍然超出了合理的范围。九、生态工具与部署建议9.1 立即行动清单针对IIS管理员优先级P0立即执行识别暴露面清查所有互联网暴露的IIS服务器确认HTTP/2是否启用评估业务影响确定禁用HTTP/2对业务的影响范围部署前端防护如果可能在IIS前部署HAProxy、Imperva或Cloudflare优先级P1本周内完成配置资源限制为IIS应用程序池设置内存上限和回收策略启用监控告警设置内存使用率、连接数等关键指标的告警制定应急预案准备在发现攻击时快速禁用HTTP/2的脚本和流程优先级P2持续跟踪关注微软公告订阅Microsoft Security Response CenterMSRC更新测试补丁在测试环境中验证补丁效果准备好快速部署9.2 代码级别的防护示例对于使用ASP.NET Core Kestrel的部署可以参考以下配置增强防护// Program.cs 或 Startup.csbuilder.WebHost.ConfigureKestrel(options{// 限制HTTP/2并发流数量options.Limits.Http2.MaxStreamsPerConnection100;// 缩短连接超时options.Limits.KeepAliveTimeoutTimeSpan.FromSeconds(20);// 启用请求速率限制options.Limits.MaxConcurrentConnections1000;});// 使用ASP.NET Core速率限制中间件app.UseRateLimiter(newRateLimiterOptions().AddFixedWindowLimiter(fixed,options{options.PermitLimit100;options.WindowTimeSpan.FromSeconds(10);}));9.3 长期架构建议分层防御不要将IIS直接暴露在公网前端至少有一层反向代理或WAF默认拒绝对于非必要的协议特性如HTTP/2默认禁用按需开启定期审计定期审查HTTP/2配置对照最新的安全公告进行调整应急演练定期演练“禁用HTTP/2”的应急流程确保在攻击发生时能快速响应十、总结与趋势判断10.1 核心结论CVE-2026-49975是CVE-2023-44487在IIS中的“进化版”。两者共享HTTP/2流管理的“基因”但CVE-2026-49975通过叠加HPACK压缩炸弹和流控停滞技术实现了更高的攻击效率和更大的破坏力。对于IIS用户而言形势尤为严峻CVE-2023-44487的补丁不覆盖CVE-2026-49975的攻击向量CVE-2026-49975的官方补丁至今未发布PoC代码已公开扫描活动已出现当前最实际的缓解方案是在前端部署能够强制限制请求头数量的代理或WAF或在评估业务影响后暂时禁用HTTP/2。10.2 趋势判断趋势一AI辅助漏洞发现将成为常态CVE-2026-49975的发现过程证明AI模型已经具备了分析公开代码库、识别漏洞组合的能力。Calif使用OpenAI的Codex发现了这个漏洞这预示着未来将有更多由AI发现的漏洞。安全团队需要做好“AI加速漏洞披露”的准备。趋势二协议层攻击将更加“组合化”CVE-2026-49975并非单一漏洞而是三个已知技术的组合。这种“漏洞链”思路正在成为攻击者的主流方法论。单一漏洞的修复可能不再足够安全团队需要从系统层面思考防御。趋势三IIS的安全响应速度面临挑战从CVE-2023-44487到CVE-2026-49975微软的响应速度始终落后于Nginx和Apache。对于依赖IIS的组织建议建立“不等待微软补丁”的独立防御能力——包括前端防护、资源限制和监控告警。趋势四HTTP/2的“技术债”正在集中爆发HPACK2015年引入、流控2015年引入、RST_STREAM2015年引入——这些HTTP/2的核心特性在近十年后被证明存在安全设计缺陷。随着攻击者对这些机制的深入理解更多类似的攻击手法可能会出现。10.3 最后的提醒CVE-2026-49975的CVSS评分为7.5高危但考虑到单客户端即可在20秒内耗尽32GB内存实际风险可能被低估了。对于IIS管理员现在不是观望的时候。立即评估您的暴露面部署前端防护配置资源限制——在微软的官方补丁到来之前这些措施可能是保护您服务器的唯一防线。本文基于2026年6月公开的安全公告撰写包括但不限于SecLists邮件列表、HAProxy官方博客、Imperva安全公告、SOC Prime漏洞分析、Cybersecurity Help漏洞数据库以及Calif原始披露。所有技术细节均可通过上述来源验证。
