Critical RCE Vulnerability in Apache HTTP Server
346 points • 18h ago • Article Link

已发现一个关键同步漏洞,编号为 CVE-2026-119618 。该漏洞存在于 Apache HTTP Server 的 HTTP/2 模块中,具体位于 mod_http2 组件。该高严重性问题由 Anthropic 和 Google Cloud 的研究人员发现,根源在于 assign_headers 函数内部的并发执行竞态条件。由于对共享资源的处理不当,攻击者可能借此造成堆内存损坏,从而在远程且无需身份验证的情况下实现远程代码执行。若利用成功,攻击者将能够以与 Web 服务器进程相同的权限执行任意命令。

该风险影响范围较大,尤其是在云环境中,已被入侵的 Apache 实例可能成为更大规模攻击的突破口。由于此类实例通常承载容器化或虚拟化工作负载,它们可作为横向移动的切入点,进而暴露敏感的元数据端点或相邻的微服务。根据 Wiz 的数据,目前约 64% 的云环境包含易受该特定 CVE 影响的资源。此外,约 51% 的云环境被发现存在公开暴露的实例——尽管目前尚无可用漏洞利用手段,也缺乏野外正在发生攻击的证据,但这会显著增加外部被利用的可能性。

该漏洞影响 Apache HTTP Server 版本 2.4.55 至 2.4.70,以及独立的 mod_h2 模块版本 2.0.8 至 2.0.42 。为修复该问题,建议安全与工程团队将 Apache HTTP Server 部署升级至 2.4.71 或更高版本,并将所有独立 mod_h2 模块更新到 2.0.42 之后的版本。上述更新将针对 assign_headers 函数中发现的同步缺陷进行修补。

对于因运行条件限制而无法立即完成打补丁的组织,可采用临时缓解措施。团队可以通过禁用 HTTP/2 支持并将协议限制为 HTTP/1.1 来移除攻击向量。具体做法是修改服务器配置文件(例如 httpd.conf),确保只启用 HTTP/1.1 。尽管这并非永久修复方案,但在安排正式升级之前,它能够有效保护环境,防止竞态条件带来的风险。

187 comments • Comments Link

- Apache HTTP Server 的 mod_http2 模块存在严重漏洞,可能在并发线程触发的竞态条件下导致堆损坏,从而被远程利用执行代码(RCE)。

- 起初的部分报道将其描述为内存损坏且未确认是否能实现 RCE,但 Red Hat 等官方来源已证实:在默认配置下的服务器存在可靠的利用程序。

- 使用 `a2dismod http2` 禁用 HTTP/2 模块是有效的即时缓解措施;建议用户检查自身服务器配置,并在补丁发布后尽快更新。

- 该漏洞再次凸显了用 C 语言开发的软件在并发与数据竞争安全方面的持续风险,也引发了关于 Rust 等内存安全语言在理论层面是否更安全的新一轮讨论。

- 漏洞披露过程反映了当下安全研究的发展态势:AI 驱动的自动化发现,以及 Anthropic 、 Google 等主要机构的协同报告,正在持续揭示遗留基础设施中的关键缺陷。

- 围绕本次事件的讨论延伸到更广泛的"HTTP/2 与 HTTP/1.1"之争:有人认为现代 HTTP 协议的复杂度增加带来的收益不足,尤其是在其引入新的攻击面之后。

- 尽管市场上已有 Nginx 、 Caddy 以及基于 Rust 的 Web 服务器等现代替代方案,但由于既有工作流、遗留兼容需求(如 `.htaccess` 或 `mod_shib`)以及对成熟环境"即装即用"的既定认知,Apache 依然被广泛采用。

- Apache 在共享托管与特定企业环境中的普遍使用,意味着相当一部分云部署仍然存在脆弱性,这进一步强调了稳健的配置管理与自动化补丁策略的重要性。

- 关于 AI 在安全领域的作用,各方仍有分歧:一部分人认为 AI 可能类似于传统模糊测试(fuzzing)工具,帮助挖掘漏洞;但也有人反对基础模型的伦理问题,并质疑未经验证的 AI 生成补丁的质量。

- 现代软件生态系统的复杂性让组织很难持续追踪依赖项,尤其是当遗留配置由缺乏服务器内部专门知识的团队维护时。

这次讨论体现了在维护成熟且对遗留系统至关重要的基础设施、以及面对复杂 C 语言 Web 服务器固有的持续安全挑战之间的矛盾。尽管 Apache 仍支撑着互联网的大部分运行,但在其 HTTP/2 实现中曝出的高严重性 RCE 漏洞促使运营方采取即时响应措施,例如禁用相关模块。本事件也再次点燃了关于现代协议价值与攻击面、内存安全语言在关键系统中的作用,以及漏洞发现与披露日益自动化的长期争论。总体来看,普遍共识是:Apache 作为稳定且功能丰富的基础组件依然重要,但其持续安全性在很大程度上取决于管理员的勤勉——及时更新配置并强化对已知利用手法的防护。