CVE-2026-42926 NGINX HTTP/2 帧注入实验室

一个受控的网络安全实验室，用于验证和比较与 CVE-2026-42926 相关的行为，这是一个影响特定 NGINX 版本的 HTTP/2 帧注入 问题，当使用有漏洞的代理配置时。

本仓库仅用于防御性研究、补丁验证、配置审计和受控的实验室复现。

分类：HTTP/2 帧注入 受影响版本：NGINX 1.29.4 至 1.30.0 修复版本：NGINX 1.30.1+ / 1.31.0+

安全须知

请仅在你拥有或明确授权测试的隔离实验室环境中使用本项目。

未经书面授权，请勿对第三方系统、公共基础设施、共享环境或生产服务运行此项目。

推荐的隔离方式：

• 本地虚拟机
• 一次性容器
• 私有测试主机
• 不可路由的实验室网络

本实验室的作用

该实验室检查目标 NGINX 二进制文件和配置是否满足复现该问题所需的条件，向测试位置发送精心构造的请求，并检查受控的上游日志器，以寻找注入的类似 HTTP/2 帧的字节到达上游侧的痕迹。

正常的验证模式是：

1. 使用有漏洞的 NGINX 构建运行相同的易受攻击代理配置。
2. 使用已打补丁的 NGINX 构建运行相同的易受攻击代理配置。
3. 比较上游证据和脚本判定结果。

预期结果：

• 有漏洞的构建：可能观察到注入证据。
• 已打补丁的构建：不应观察到注入证据。

仓库内容

要求

• Linux 或 macOS 终端环境
• bash
• python3
• php
• PHP cURL 扩展
• 你想要比较的版本的 NGINX 测试二进制文件
• 绑定配置的 NGINX 监听端口的权限

对于容器化工作流：

• Docker
• Docker Compose v2

示例配置监听端口 80，通常需要 root 权限。对于非特权本地实验室，将 nginx_vulnerable.conf 中的 listen 80; 更改为可用的高位端口，例如 8080，然后在 PHP 命令中使用匹配的目标 URL。

设置

使 shell 脚本可执行：

chmod +x nginx_config_verify.sh run_lab_comparison.sh

确认 PHP 有 cURL 支持：

php -m | grep -i curl

确认每个 NGINX 二进制文件可以打印版本：

/path/to/nginx -V

实验室配置

提供的 nginx_vulnerable.conf 包含所需的测试模式：

location /exploit {
    proxy_pass http://127.0.0.1:8081;
    proxy_http_version 2;
    proxy_set_body $request_body;
    proxy_set_header Host $host;
    proxy_set_header Content-Length $content_length;
}

重要细节：

• proxy_http_version 2 启用对上游日志器的 HTTP/2 代理。
• proxy_set_body $request_body 使用客户端控制的请求体。
• client_max_body_size 20m 允许验证脚本使用的构造的 16 MiB 请求体。
• 上游日志器默认监听 127.0.0.1:8081。

docker/nginx_vulnerable.docker.conf 中的 Docker 特定配置保留了相同的易受攻击代理模式，但监听容器端口 8080 并代理到 Compose 服务名 upstream:8081。

Docker 快速入门：NGINX 1.29.4 实验室

Dockerfile 从源代码构建 NGINX 1.29.4，并安装实验室所需的 PHP/Python 工具。然后 Compose 从同一镜像运行三个服务：

• upstream: 原始 HTTP/2 帧日志器
• nginx: 使用 docker/nginx_vulnerable.docker.conf 的易受攻击的 NGINX 1.29.4
• runner: 一次性 PHP 验证命令

构建实验室镜像：

docker compose build

启动上游日志器和易受攻击的 NGINX：

docker compose up -d upstream nginx

确认捆绑的 NGINX 版本：

docker compose exec nginx nginx -V

在 Compose 网络内运行验证脚本：

docker compose --profile run run --rm runner

运行器使用以下容器内参数：

php /lab/cve_2026_42926_lab.php \
  http://nginx:8080/exploit \
  /lab/upstream_logs \
  /lab/nginx_config_verify.sh \
  /usr/local/nginx/sbin/nginx \
  /lab/docker/nginx_vulnerable.docker.conf \
  /exploit

生成的上游日志写入主机目录：

./upstream_logs/

NGINX 服务也通过以下地址暴露给主机：

http://localhost:8080/version

停止并移除实验室容器：

docker compose down

快速入门：单次验证运行

启动受控的上游日志器：

python3 upstream_frame_logger.py 8081 ./upstream_logs

在另一个终端中，使用示例配置启动 NGINX：

/path/to/nginx -c "$PWD/nginx_vulnerable.conf"

运行验证脚本：

php cve_2026_42926_lab.php \
  http://localhost/exploit \
  ./upstream_logs \
  ./nginx_config_verify.sh \
  /path/to/nginx \
  "$PWD/nginx_vulnerable.conf" \
  /exploit

运行后停止 NGINX：

/path/to/nginx -s stop

如果你更改了 NGINX 监听其他端口，请更新第一个参数。例如：

php cve_2026_42926_lab.php http://localhost:8080/exploit ./upstream_logs ./nginx_config_verify.sh /path/to/nginx "$PWD/nginx_vulnerable.conf" /exploit

快速入门：易受攻击版本与已补丁版本的比较

设置两个 NGINX 二进制文件的路径并运行比较框架：

VULNERABLE_NGINX=/usr/local/nginx_1.29.4/sbin/nginx \
PATCHED_NGINX=/usr/local/nginx_1.30.1/sbin/nginx \
bash run_lab_comparison.sh

可选的配置覆盖：

VULNERABLE_NGINX=/path/to/vulnerable/nginx \
PATCHED_NGINX=/path/to/patched/nginx \
VULNERABLE_CONFIG="$PWD/nginx_vulnerable.conf" \
PATCHED_CONFIG="$PWD/nginx_vulnerable.conf" \
bash run_lab_comparison.sh

比较脚本写入：

• vulnerable_result.txt
• patched_result.txt
• upstream_logs_vulnerable/
• upstream_logs_patched/

手动配置检查

当你只想检查配置是否包含易受攻击模式时，直接使用 nginx_config_verify.sh：

./nginx_config_verify.sh /path/to/nginx "$PWD/nginx_vulnerable.conf" /exploit

辅助脚本检查：

• proxy_http_version 2
• 使用变量的 proxy_set_body
• 至少 16 MiB 的 client_max_body_size

脚本参数

cve_2026_42926_lab.php 接受位置参数：

php cve_2026_42926_lab.php <target_url> <upstream_log_dir> <config_script> <nginx_binary> <nginx_config> <location> [version_url]

默认值：

判定结果与退出码

cve_2026_42926_lab.php 返回三种判定之一：

阳性证据要求脚本关联运行标记、观察到的上游帧头、注入帧标志以及受影响的 NGINX 版本。

输出产物

上游日志器写入类似命名的 JSON 文件：

frames_<timestamp>.json

每个日志包含解析后的 HTTP/2 帧元数据、有效载荷摘要、字节偏移、注入检测标志和运行关联字段。

比较框架为易受攻击和已补丁的运行存储单独的日志目录，以使两次执行的证据不会混合。

故障排除

如果 PHP 脚本报告配置辅助脚本不可执行，请运行：

chmod +x nginx_config_verify.sh

如果请求返回 413 Request Entity Too Large，请将 client_max_body_size 增加到至少 16m；示例配置使用 20m。

如果没有创建上游日志，请检查：

• upstream_frame_logger.py 是否正在运行。
• NGINX 是否正在代理到 127.0.0.1:8081。
• 目标 URL 是否指向配置的 NGINX 监听器。
• 请求是否到达 /exploit 位置。

如果 NGINX 无法绑定端口 80，请在实验室环境中以适当的权限运行，或者将配置更改为高位端口，如 8080。

如果比较结果不确定，请检查 vulnerable_result.txt、patched_result.txt 以及相应的上游日志目录，查找失败的前提条件。

许可证

本项目采用 MIT 许可证授权。详情请参见 LICENSE。