深度解析

Apache HTTP Server HTTP/2 RCE，2.4.71 已修复（CVE-2026-119618）

Apache HTTP Server 的 mod_http2 存在线程竞态，未认证的 HTTP/2 客户端可破坏内存并可能执行代码；2.4.71 已修复。

Ostorlab Team 2026年11月12日

TL;DR

Apache HTTP Server 的 mod_http2 会把合成的 Content-Length 头写入与连接线程共享的表。Apache 将该漏洞评为严重，Red Hat 给出 CVSS v3.1 9.8 分。
启用 h2 或 h2c 的 2.4.55 至 2.4.70 受影响。仅使用 HTTP/1.1 的服务器不受影响。
Red Hat 表示公开研究已演示了针对默认配置服务器的可靠利用。没有链接公开利用代码，也没有已知的实际利用；截至 2026-11-12，该 CVE 不在 CISA KEV 中。
升级到 2.4.71 或您所在发行版的修复包。如果无法升级，请禁用 HTTP/2；参见“如何修复？”。

我受影响吗？

只有以下条件全部成立时才受影响：

您运行 Apache HTTP Server 2.4.55 至 2.4.70。
mod_http2 已加载并启用了 HTTP/2：TLS 使用 Protocols h2 http/1.1，明文使用 h2c。
不可信客户端可以访问该 HTTP/2 监听端口，无论是直接访问还是通过转发 HTTP/2 的代理。

仅配置 HTTP/1.1 的服务器不受影响。Red Hat 表示 RHEL 8 及更早版本不受影响，因为其 mod_http2 早于 2.0.8。

RHEL 9 和 RHEL 10 受影响，但被评为 Important。Red Hat 解释说，每个 HTTP/2 流都从单独的内存分配器分配，这大大增加了利用难度。Apache 公告将 mod_h2 2.0.8 至 2.0.42 列为受影响；2.4.71 包含修复后的模块。

分支	受影响版本	修复版本
Apache HTTP Server 2.4.x	2.4.55 至 2.4.70	2.4.71

根据 W3Techs，Apache 被 20.9% 的已知 Web 服务器网站使用。受影响范围只是其中一部分，因为必须启用 HTTP/2。

检查已安装版本以及 HTTP/2 是否启用：

# Debian and Ubuntu
apache2 -v
apache2ctl -M | grep http2

# RHEL, Fedora and other RPM distributions
httpd -v
httpd -M | grep http2

# The Protocols directive shows whether h2 or h2c is enabled
grep -R "Protocols" /etc/apache2 /etc/httpd 2>/dev/null

对于容器，请检查正在运行的进程，而不是新拉取的镜像：

docker exec <container> apache2 -v
docker exec <container> apache2ctl -M | grep http2

在 RHEL 上，修复后 httpd -v 仍显示基础 2.4 版本。安全更新修改的是 mod_http2 包，因此请将该包与公告对比：

rpm -q mod_http2

根据 Red Hat 的 CVE 页面，RHEL 9.9 提供 mod_http2-2.0.26-7.el9_9.1，RHEL 10.3 提供 mod_http2-2.0.29-5.el10_3.1。这些分支上更早的 mod_http2 构建受影响。

如何修复？

升级到 Apache HTTP Server 2.4.71，或安装您所在发行版发布的修复版 mod_http2 包。Red Hat 于 2026-11-11 发布向后移植。Debian 的 DSA-6620-1 为 Debian 13 列出 apache2 2.4.71。

更新软件包： ```bash # Debian and Ubuntu sudo apt update sudo apt install --only-upgrade apache2

# RHEL and Fedora sudo dnf update httpd mod_http2 2. 确认修复后的构建。在 Debian 13 上，`apache2 -v` 显示 2.4.71。较旧的 Debian 和 Ubuntu 版本会将修复向后移植到现有系列中，因此请将 `dpkg -s apache2` 显示的版本与对应版本的 DSA 或 USN 中的版本对比。在 RHEL 上，将 `rpm -q mod_http2` 与公告中的包版本对比。 3. 重启 Apache 以加载新模块：bash sudo systemctl restart apache2 # Debian and Ubuntu sudo systemctl restart httpd # RHEL and Fedora ``` 4. 重新构建并重新创建每个包含 Apache 的容器镜像。如果运行中的容器仍使用旧层，仅拉取新镜像是不够的。

如果从源码构建，请使用 Apache HTTP Server 项目的 2.4.71 发布包。

如果无法立即升级，请禁用 HTTP/2。漏洞位于 HTTP/2 请求路径中，移除该路径即可关闭它。代价是失去多路复用的性能优势。

在 Debian 和 Ubuntu 上禁用模块并重启： bash sudo a2dismod http2 sudo systemctl restart apache2
在 RHEL 和 Fedora 上注释掉 LoadModule http2_module 行，确保 Protocols 不包含 h2 或 h2c，然后重启： bash sudo systemctl restart httpd
在任何发行版上，用 apache2ctl -M | grep http2 或 httpd -M | grep http2 确认模块已消失。没有输出表示 HTTP/2 已关闭。

终止 HTTP/2 并向 Apache 转发 HTTP/1.1 的反向代理会在后端移除此路径。如果代理本身运行受影响的 Apache，则仍可能受影响。禁用 HTTP/2 是临时缓解措施，不是修复；修复后的模块才是长期方案。

根本原因是什么？

mod_http2 将 HTTP/2 帧转换为内部的 request_rec，assign_headers() 将解析后的请求头复制到请求的头表中。缺陷在于某个分支把合成的 Content-Length 头写入了共享的源表，而不是请求自己的副本。

该函数位于 modules/http2/h2_request.c。以下是 2.4.70 标签中的代码：

static void assign_headers(request_rec *r, const h2_request *req,
                           int no_body, int is_connect)
{
    const char *cl;

    r->headers_in = apr_table_clone(r->pool, req->headers);

    if (req->authority && !is_connect) {
        ...
        apr_table_setn(r->headers_in, "Host", req->authority);
    }

    /* Unless we open a byte stream via CONNECT, apply content-length guards. */
    if (!is_connect) {
        cl = apr_table_get(req->headers, "Content-Length");
        if (no_body) {
            if (!cl && apr_table_get(req->headers, "Content-Type")) {
                /* If we have a content-type, but already seen eos, no more
                 * data will come. Signal a zero content length explicitly.
                 */
                apr_table_setn(req->headers, "Content-Length", "0");
            }
        }

req->headers 是为连接上的流解析出的头表。r->headers_in 是在请求池中分配的副本，也是 Apache 模块读取的表。函数以 const h2_request * 接收 req，因此不应修改它。同一代码片段中的 Host 分支写入 r->headers_in，显示了预期目标。Content-Length 分支是例外。

触发条件很窄，且不需要请求体。当客户端在 HEADERS 帧上设置 END_STREAM 时，no_body 为真，因此不会有请求体跟随。如果该请求带有 Content-Type 且没有 Content-Length，该分支就会执行。

apr_table_setn() 添加新键，这会扩展表并在表的池中分配内存。该池属于连接和流，而写入在流的 worker 线程上执行。Red Hat 将此描述为 worker 线程通过共享的无锁分配器写入连接线程的内存。

APR 表和内存池不是线程安全的。因此，对同一表的并发分配或遍历可能破坏堆。公告将该漏洞归类为同步不当的并发执行问题（CWE-362），Apache 的描述直接点名 assign_headers()。

如何被利用？

攻击者打开到服务器的 HTTP/2 连接，TLS 使用 h2，明文使用 h2c。
攻击者在该连接上发送大量并发 HEADERS 请求。每个请求带有 :method、:path、:authority 和 Content-Type，并在没有 Content-Length 的情况下设置 END_STREAM。
每个请求在 no_body 已设置的情况下到达 worker 线程的 assign_headers()。worker 将 Content-Length: 0 添加到共享的 req->headers 表。
当 worker 在该表中分配内存时，连接线程和其他 worker 可能读取或分配同一表和内存池。竞态破坏堆。
Apache 表示这种破坏可能导致远程代码执行。worker 或服务器进程崩溃是更简单的结果。

公告没有发布利用代码。Red Hat 表示公开研究已演示了针对启用 mod_http2 的默认配置服务器的可靠利用，并因此将该漏洞评为严重。截至 2026-11-12，没有已知的实际利用。

攻击如何展开？

未认证的 HTTP/2 客户端发送一个没有请求体、带有 Content-Type 但没有 Content-Length 的请求，worker 的合成头写入与连接线程的分配器发生竞态，直到堆被破坏。

flowchart LR
    A["HTTP/2 客户端<br/>HEADERS + END_STREAM"] --> B["mod_http2 设置<br/>no_body"]
    B --> C["assign_headers()<br/>有 Content-Type，无 Content-Length"]
    C --> D["apr_table_setn(req->headers)<br/>共享表，worker 线程"]
    D --> E["连接线程的<br/>共享分配器"]
    E --> F["堆破坏"]
    F --> G["崩溃或远程<br/>代码执行"]

攻击者能做什么？

能够访问 HTTP/2 监听端口的未认证攻击者可以使服务器崩溃。如果堆破坏被塑造成有用的原语，攻击者可以以运行 Apache 的用户身份执行代码。Apache 公告称该漏洞可能导致远程代码执行。Red Hat 更进一步，称成功利用可执行任意命令、完全控制服务器进程并访问敏感数据。

Red Hat 将该漏洞评为 CVSS v3.1 9.8，CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H。

条件是“我受影响吗？”中列出的条件：受影响的 2.4 版本、已加载 mod_http2、启用 HTTP/2 以及网络可达。攻击者不需要账户，也不需要用户交互。

利用依赖于赢得竞态，因此可靠性随负载、分配器布局和并发流数量而变化。Red Hat 因此将 RHEL 9 和 RHEL 10 评为 Important 而非 Critical，但仍将其列为受影响。

崩溃是拒绝服务，不是代码执行。消息源称代码执行是可能的，Red Hat 称已在研究中演示。两个消息源都没有发布可用的利用或受害者报告。

为什么修复有效？

补丁修改了 assign_headers() 中的一行，使合成头写入请求自己的副本：

@@ -350,7 +350,7 @@ static void assign_headers(request_rec *r, const h2_request *req,
                 /* If we have a content-type, but already seen eos, no more
                  * data will come. Signal a zero content length explicitly.
                  */
-                apr_table_setn(req->headers, "Content-Length", "0");
+                apr_table_setn(r->headers_in, "Content-Length", "0");
             }
         }

r->headers_in 在请求池中分配，只有处理该流的 worker 使用它。创建副本后，共享的 req->headers 表不再被修改，因此 worker 不再写入连接线程的内存。合成头仍会到达下游模块，因为它们读取 r->headers_in。

该修改覆盖了 assign_headers() 中唯一写入 req->headers 的位置。同一函数中另一个头写入（Host）已经使用 r->headers_in。修复不改变 HTTP/2 帧格式或请求体处理。

如何检查是否已遭入侵？

该漏洞没有公开的入侵指标。成功利用可能除了被破坏的内存外不留痕迹，失败的尝试可能只导致 worker 崩溃。

在 Apache 错误日志中查找崩溃和子进程异常退出，尤其是在修复前暴露过 HTTP/2 的服务器上：

grep -Ei "segfault|signal 11|child pid .* exit|AH00051" /var/log/apache2/error.log
grep -Ei "segfault|signal 11|child pid .* exit|AH00051" /var/log/httpd/error_log

在 systemd 主机上，列出 Apache 二进制文件的 core dump：

coredumpctl list apache2
coredumpctl list httpd

崩溃是线索，不是利用的证据，因为其他缺陷和资源限制也可能杀死 worker。如果在运行受影响构建的 HTTP/2 服务器上发现反复崩溃，请在重启前保留日志和 core dump。在完成审查之前，将该主机视为可能已遭入侵。

时间线

2026-10-26：Anthropic 的 OSS Scanner 以 ANT-2026-MAPKT6MZ 向 Apache 安全团队报告该漏洞。
2026-11-03：Google Cloud Vulnerability Research 的 Anthony Weems 和 Simon Scannell 独立报告该漏洞。
2026-11-09：修复以提交 824beab 进入 2.4.x 分支，该提交是 master 提交 5ed3928 的 cherry-pick。
2026-11-11：Apache 发布 2.4.71 和 CVE-2026-119618 公告。Red Hat 同日发布修复后的 mod_http2 包和公告。

从首次报告到修复版本共 16 天。 — 从首次报告到修复版本的路径，16 天后。来源：Apache HTTP Server 安全页面和修复提交，2026 年 11 月 12 日检查

常见问题

仅使用 HTTP/1.1 的服务器受影响吗？

不受影响。漏洞位于 HTTP/2 请求路径中。加载了 mod_http2 但只协商 HTTP/1.1 的服务器不会到达 assign_headers()。

我的反向代理终止 TLS。Apache 后端会受影响吗？

取决于代理与 Apache 之间的协议。如果代理转发 HTTP/2，后端会受影响。如果转发 HTTP/1.1，后端路径已关闭，但代理本身可能运行受影响的 Apache。

有公开利用吗？

Apache 公告和 CVE 记录都没有链接公开利用代码。Red Hat 表示公开研究已演示了针对启用 mod_http2 的默认配置服务器的可靠利用。

CVE-2026-119618 在 CISA KEV 中吗？

不在。截至 2026-11-12，该 CVE 不在 CISA 的 Known Exploited Vulnerabilities 目录中，也没有已知的实际利用。

哪些 RHEL 版本受影响？

RHEL 9 和 RHEL 10 受影响，被评为 Important。RHEL 8 及更早版本不受影响，因为其 mod_http2 早于 2.0.8。请安装 Red Hat 公告中为您的分支列出的 mod_http2 包版本。

为什么 RHEL 更新后 `httpd -v` 仍显示 2.4.57？

Red Hat 将修复向后移植到 mod_http2 包，而不是更改 httpd 版本。请将 rpm -q mod_http2 与修复后的包版本对比，而不是 httpd 版本字符串。

参考文献

Apache HTTP Server 安全页面，CVE-2026-119618 公告，2026-11-11 发布：https://httpd.apache.org/security/vulnerabilities_24.html（2026 年 11 月 12 日检查）
CVE-2026-119618 记录，Apache Software Foundation CNA，2026-11-11 发布：https://www.cve.org/CVERecord?id=CVE-2026-119618（2026 年 11 月 12 日检查）
2.4.x 分支修复提交，824beab，2026-11-09：https://github.com/apache/httpd/commit/824beab9b9424d6cfb29595248fdbf6c3dddeab1（2026 年 11 月 12 日检查）
master 上游修复提交，5ed3928，2026-11-09：https://github.com/apache/httpd/commit/5ed39287660daacd1233cb9bbc984b25fa9a4fe3（2026 年 11 月 12 日检查）
Red Hat 的 CVE-2026-119618 页面，CVSS v3.1 9.8 和修复后的 mod_http2 包，2026-11-11 发布：https://access.redhat.com/security/cve/CVE-2026-119618（2026 年 11 月 12 日检查）
Debian 安全跟踪器，CVE-2026-119618、DSA-6620-1 和修复后的 apache2 2.4.71：https://security-tracker.debian.org/tracker/CVE-2026-119618（2026 年 11 月 12 日检查）
W3Techs，Apache 使用率，占已知 Web 服务器网站的 20.9%：https://w3techs.com/technologies/details/ws-apache（2026 年 11 月 12 日检查）

ostorlab/KEV 开源

# 免费开源：扫描您自己的主机，查找与此类似的已知被利用漏洞。

$ pip install -U ostorlab
$ git clone https://github.com/Ostorlab/KEV && cd KEV
$ ostorlab scan run --install -g agent_group.yaml domain-name example.com

Ostorlab KEV 免费开源（Apache-2.0）。一条命令即可运行 Nuclei、Tsunami、Nmap、Asteroid 和 Metasploit 检测器，覆盖来自 CISA KEV 目录、Google Tsunami 和漏洞赏金计划的漏洞。

github.com/Ostorlab/KEV

标签：

security, CVE, Apache, HTTP/2, memory corruption, vulnerability