Apache HTTP/2 漏洞 CVE-2026-119618：如何排查服务器并修补至 2.4.71

运行 HTTP/2 的 Web 服务器可能会被未经登录的陌生人接管。这就是 Apache HTTP Server 的 HTTP/2 模块中的严重缺陷 CVE-2026-119618 背后的风险，目前修复补丁已经发布。

今天是 2026 年 11 月 13 日。Apache 于 11 月 11 日发布了 2.4.71 版本以堵塞此漏洞，安全团队现在都在问同一个问题：我们真的受影响了吗？确切的答案不仅仅取决于版本号。它取决于是否启用了 HTTP/2、您的 Linux 发行版厂商是否已修补其软件包，以及流量如何到达 Apache。本指南以 Acme 公司的系统管理员 Rohit 为例，详细阐述这三个方面。

简而言之：发生了什么

HTTP/2 是 Web 主流协议的较新版本。其核心理念是多个请求和响应可以同时共享一个连接，从而让网站更快。在 Apache 中，提供这一功能的模块是 mod_http2.

。共享同一个连接意味着服务器的多个部分同时协同工作，它们必须谨慎管理谁使用哪块内存。根据 Red Hat 的技术评估，这里的防护机制失效了。一个 工作线程 （服务器中负责处理单个请求的部分）可能会写入由 连接线程 （负责管理整个连接的部分）所拥有的内存，这是通过一个共享的无锁内存分配器发生的。问题出在名为 assign_headers()的函数中。当两个部分在未经协调的情况下写入同一块内存时，内部内存可能会遭到破坏，而内存损坏通常是运行攻击者代码的突破口。

Red Hat 为该漏洞评定的 CVSS v3.1 评分高达 9.8 分（满分 10 分）。该评分意味着攻击可通过网络发起，无需密码，也无需任何用户交互。

哪些版本受影响

Apache 列出了以下受影响的版本范围：

• Apache HTTP Server 2.4.55 至 2.4.70.
• 单独发布的 mod_h2 模块（来自 GitHub），版本为 2.0.8 至 2.0.42.

已修复的版本为 Apache HTTP Server 2.4.71，或明确包含该修复的厂商软件包。

Red Hat 为其自身平台补充了重要细节：

• RHEL 8 及更早版本不受影响，因为其中不存在有漏洞的代码。
• RHEL 9 和 RHEL 10 被评为“重要”（Important）级别而非“严重”（Critical）级别。它们的 HTTP/2 流使用独立的分配器，这使得利用难度大大增加。它们仍然需要更新，Red Hat 已于 11 月 11 日针对多个 RHEL 9 和 10 流发布了修复程序。

攻击者实际上能获取什么

成功利用该漏洞可使攻击者控制 Web 服务器进程。但这并不等同于完全控制整台机器。攻击者能够访问的内容取决于 Apache 进程能够访问的内容：应用程序数据、其可写入的网站目录、配置文件中存储的凭据，以及内部网络上的任何后端服务（如数据库）。

因此，在以低权限用户运行且隔离良好的服务器上，造成的破坏要小于 Apache 可以读取机器上所有机密的服务器。现在也是检查这一点的绝佳时机。

您的服务器真的暴露了吗？

许多团队在这两个方向上都容易产生误判。单凭版本号并不能证明存在危险，而看似安全的公开网站也不能证明绝对安全。

仅加载模块还不足以构成风险。 卢森堡的 CIRCL 指出，只有当服务实际接受 HTTP/2 时，易受攻击的路径才是可达的。如果加载了 mod_http2 但没有监听器提供 HTTP/2，该路径就是不可达的。

两种 HTTP/2 都算在内。 基于 TLS 的加密 HTTP/2 被称为 h2。无 TLS 的明文 HTTP/2 被称为 h2c。在任何监听器上启用其中任何一种都至关重要。

虚拟主机可能存在差异。 Apache 允许您针对整台服务器设置协议，也可以针对每个虚拟主机分别设置。仅检查主配置文件可能会漏掉某个自行开启了 HTTP/2 的站点。

代理会改变这一局面。 如果前端部署了 CDN、负载均衡器或反向代理，对访客使用 HTTP/2，但对 Apache 仅使用 HTTP/1.1，那么外部 HTTP/2 会话本身并不会暴露此漏洞。但如果能够直接访问源站服务器、内部监听器，或者代理将 HTTP/2 转发给 Apache，则会暴露该漏洞。

Rohit 的经历说明了为什么这一点很重要。Acme 的主网站位于 CDN 之后，因此公开扫描显示所有地方都支持 HTTP/2。但在内网中，他发现了三种情况：主站的 Apache 仅从 CDN 接收 HTTP/1.1 流量；内部 wiki 直接通过 h2 访问；还有一个旧的营销虚拟主机自行启用了 h2c。这三种情况中有两种需要紧急处理，而公开扫描完全无法体现这些情况。

分步排查：Rohit 当下的操作

步骤 1：排查每台 Apache 服务器及其版本

列出服务器清单，然后逐一检查。不同发行版的命令名称有所不同。

# RHEL, Rocky, Alma, Fedora
httpd -v
# Debian, Ubuntu
apache2 -v

请记住，厂商通常会在不更改主版本号的情况下修复缺陷（这被称为 反向移植（backporting））。请对照您所用厂商的安全公告核对软件包，而不仅仅是查看版本字符串。

# RHEL family: is the fix for this CVE available or installed?
dnf updateinfo list --cve CVE-2026-119618
# Debian and Ubuntu: does the installed package mention the CVE?
apt changelog apache2 | grep -i CVE-2026-119618

步骤 2：检查是否实际提供了 HTTP/2

首先查看是否加载了该模块，然后搜索每个配置文件中的协议设置，包括虚拟主机。

# Is mod_http2 loaded?
apachectl -M 2>/dev/null | grep -i http2
# Where is HTTP/2 enabled? Look for h2 or h2c on any Protocols line
grep -RniE '^\s*Protocols' /etc/httpd/ /etc/apache2/ 2>/dev/null

然后从外部和内部进行测试。 --http2 用于请求基于 TLS 的 h2，而 --http2-prior-knowledge 则尝试明文 h2c。若结果显示 2 ，则表示使用了 HTTP/2。

curl -s -o /dev/null -w '%{http_version}\n' --http2 https://app.example.com/
curl -s -o /dev/null -w '%{http_version}\n' --http2-prior-knowledge http://203.0.113.10/

不仅要针对公开网站运行这些命令，还要针对源站地址和内部域名运行。

步骤 3：修补至 2.4.71 或厂商的修复软件包

应用厂商提供的更新（如果您从源码运行 Apache，则编译 2.4.71），然后重启服务以确保新代码真正运行。软件包更新后执行 reload 并不总是足够，restart 才是稳妥的选择。

# RHEL family
sudo dnf update httpd mod_http2
sudo systemctl restart httpd
# Debian and Ubuntu
sudo apt update && sudo apt install --only-upgrade apache2
sudo systemctl restart apache2

然后重复步骤 1，确认正在运行的构建版本确为修复后的版本。

步骤 4：如果尚无法打补丁，请关闭 HTTP/2

作为临时措施，可将协议限制为 HTTP/1.1。将此配置写入主配置以及每个自行设置协议的虚拟主机中，并移除所有 h2 和 h2c 条目：

Protocols http/1.1

验证配置并应用，然后使用步骤 2 中的 curl 命令重新测试。您期望看到的是 1.1，而不是 2.

apachectl configtest && sudo systemctl reload httpd    # or apache2

在 Debian 和 Ubuntu 上，您也可以通过 sudo a2dismod http2来禁用该模块，随后重启服务。在完成修补重新启用 HTTP/2 之前，部分访客的页面加载速度可能会略微变慢。

步骤 5：排查过往受攻击的迹象

打补丁关上了大门，但无法告诉您此前是否有人已经潜入。CIRCL 建议审查异常的 Apache worker 崩溃、异常的子进程、Web 目录中未经授权的文件更改，以及来自服务器的异常出站连接。这些迹象单独来看都不能证实遭受了攻击，但每一项都值得仔细排查。

关于漏洞利用报告

各方消息存在分歧，因此请仔细甄别新闻标题。Red Hat 表示，公开研究表明，在启用了 mod_http2 的默认服务器上可以实现可靠的漏洞利用。Wiz 于 11 月 11 日表示，当时尚无公开的利用程序，也未在野外发现攻击活动。CIRCL 指出，PoC 演示并不等同于野外攻击。

Wiz 还报告称，在其自身数据中有 64% 的云环境包含受此漏洞影响的资源。该数据描述的是 Wiz 的数据集，而非互联网上所有 Apache 服务器的占比。

稳妥的理解方式是：这些报告中尚未证实存在已发起的攻击活动，但可行的利用技术已被证实存在，因此请尽快打补丁。

漏洞发现者以及 2.4.71 还修复了哪些问题

Apache 致谢了 Anthropic 的 OSS Scanner，以及 Google Cloud 漏洞研究团队的 Anthony Weems 和 Simon Scannell。时间线显示，Anthropic 于 10 月 26 日提交了报告，Google 于 11 月 3 日提交了报告，修复与版本发布于 11 月 11 日完成。

2.4.71 版本还修复了两个较小的问题：

• CVE-2026-106023 （重要）：在 2.4.30 至 2.4.70 版本中，mod_md 存在空指针解引用缺陷，可能导致子进程崩溃。
• CVE-2026-109163 （低危）：在 2.4.69 和 2.4.70 版本中，mod_vhost_alias 存在栈缓冲区覆盖问题。

总结

CVE-2026-119618 影响严重：无需登录、网络可达、可控制 Web 服务器。但实际受影响情况取决于是否启用了 HTTP/2 或 h2c、您所用厂商的软件包版本，以及流量如何到达 Apache。排查每台服务器，检查每个虚拟主机，修补至 2.4.71 或厂商修复版本，在等待期间关闭 HTTP/2，并回溯排查此前是否有被利用的痕迹。

有利因素

• 修复补丁已经发布，因此有明确的安全处置路径。
• 可通过单行配置关闭 HTTP/2 作为权宜之计。
• RHEL 8 及更老版本不受影响，而 RHEL 9 和 10 的利用难度更高。
• 仅与 Apache 进行 HTTP/1.1 通信的代理可以降低暴露风险。
• 此次排查是收紧 Apache 进程访问权限的良好契机。

不利因素

• 该缺陷无需登录且评分高达 9.8，因此暴露在外的服务器面临实际风险。
• 版本字符串可能具有误导性，因为厂商通常会反向移植补丁。
• 基于每个虚拟主机的独立设置容易让人遗漏某个暴露的站点。
• 关闭 HTTP/2 可能会导致部分页面的加载速度略微变慢。
• 打补丁无法查明服务器在修复前是否曾遭受攻击。

注意事项

本文仅供学习参考。主机名、IP 地址及公司名称 Acme 均为占位符，必须替换为您自己的信息。各发行版及不同版本之间的命令存在差异，因此请务必阅读厂商的安全公告，并先在非生产服务器上测试变更。关于漏洞利用和受影响范围的陈述均来自本文汇总的厂商和研究人员报告，后续可能会有变动，请在参考前与 Apache 及厂商的官方公告核对确认。

常见问题解答

• 什么是 CVE-2026-119618？ ——这是 Apache HTTP Server 的 HTTP/2 模块中的一个严重内存损坏漏洞，可允许未经身份验证的远程代码执行。
• 哪些 Apache 版本受影响？ ——Apache HTTP Server 2.4.55 至 2.4.70，以及单独的 mod_h2 模块 2.0.8 至 2.0.42 版本。
• 哪个版本修复了该漏洞？ ——于 2026 年 11 月 11 日发布的 Apache HTTP Server 2.4.71，或明确包含该修复的厂商软件包。
• 如果加载了 mod_http2 但未启用 HTTP/2，我的服务器安全吗？ ——有漏洞的路径需要服务接受 HTTP/2，因此在任何监听器上均未提供 h2 或 h2c 的服务器不会受此漏洞影响。
• 在 CDN 或负载均衡器后面安全吗？ ——仅当代理与 Apache 之间使用 HTTP/1.1 通信，且无人能直接通过 HTTP/2 访问源站服务器时才安全。
• RHEL 是否受影响？ ——RHEL 8 及更早版本不受影响；RHEL 9 和 10 被评为“重要”（Important）级别，应应用 Red Hat 的更新。
• 如何在 Apache 中临时禁用 HTTP/2？ ——设置 Protocols http/1.1 于主配置和每个虚拟主机中，运行配置测试，然后重新加载 Apache。
• 该漏洞是否正在野外被利用？ ——此处引用的报告描述了公开的 PoC 演示，但未证实存在野外攻击，因此请尽快打补丁，不必假定已有针对性的攻击活动。

标签

#apache #cybersecurity #cve2026119618 #http2 #modhttp2 #vulnerabilitymanagement #patchmanagement #linuxsecurity #webserver #devsecops