应立即升级Nginx至修复版本并审查rewrite配置：开源版升至1.30.1+/1.31.0+，Plus版至R32 P6+/R35 P2+/R36 P4+，Ingress-NGINX需换第三方修复镜像；同时扫描含?和$1等高危rewrite规则，启用ASLR与栈保护，并纳入常态化安全响应机制。
防范 Nginx 的远程代码执行（RCE）和缓冲区溢出风险，核心在于版本管理、配置审查与运行时加固三者结合。最近曝出的 CVE-2026-42945 就是典型例子：一个看似普通的 rewrite 配置，因含问号（?）和未命名捕获组（如 $1），在旧版本中会触发堆缓冲区溢出，严重时导致 RCE。这不是理论风险，而是已在生产环境复现的高危漏洞（CVSS 9.2）。
及时升级到不受影响的版本
这是最直接有效的防线。官方已明确修复该漏洞：
- NGINX 开源版：升级至 1.30.1 或 1.31.0 及更高版本
- NGINX Plus：升级至 R32 P6、R35 P2 或 R36 P4 及以上
- 使用 Ingress-NGINX 的用户需注意：1.0.0–1.14.4 均受影响，须替换为厂商提供的第三方修复镜像，不能只改 Helm 参数或重载配置
特别提醒：很多云平台或控制面板内置的 Nginx 会伪装版本号（如显示 “nginx/1.22.0”），实际内核仍是老旧分支。建议通过 nginx -V 查看完整编译参数，并比对 --version 输出与 configure arguments 中的源码路径，确认真实版本基线。
严格审查 rewrite/if/set 类配置
CVE-2026-42945 是“配置驱动型”漏洞，仅当同时满足三个条件才会触发：
- 配置中连续出现
rewrite、if或set指令 - 使用了未命名 PCRE 捕获（例如
^(.*)$后用$1引用） -
rewrite的替换字符串里包含字面量问号（?），比如rewrite ^/old(.*)$ /new$1?ref=nginx last;
建议立即执行以下操作：
- 用
grep -r "rewrite.*?" /etc/nginx/扫描所有配置文件 - 检查所有含
$1、$2等引用的rewrite行，确认是否紧邻if或set - 临时规避：将问号改为
%3F编码形式，或改用return 301+map模块替代复杂 rewrite 链
启用并验证底层内存防护机制
即使暂无法升级，也可大幅提高攻击门槛：
- 确认系统已启用 ASLR：
cat /proc/sys/kernel/randomize_va_space返回值应为 2（完全随机化） - 检查 Nginx 二进制是否带栈保护：
readelf -s $(which nginx) | grep __stack_chk_fail—— 若有输出，说明启用了-fstack-protector - 限制请求体大小，缩小攻击面：
client_max_body_size 10m;、client_header_buffer_size 1k;、large_client_header_buffers 4 8k;
这些设置不能阻止漏洞本身，但能显著增加远程代码执行的难度——CVE-2026-42945 的 RCE 利用前提是禁用 ASLR 且内存布局可控。
建立常态化安全响应机制
单一漏洞终会修复，但新风险持续出现。建议落地三项基础动作：
- 订阅 Nginx 官方安全通告邮件列表，关注
security@nginx.org发布内容 - 将 Nginx 版本纳入 CMDB 和资产扫描流程，每季度自动比对 CVE 数据库
- 在 CI/CD 流水线中加入配置语法检查（如
nginx -t）和静态规则扫描（推荐使用 nginx-config-check 工具识别高危指令组合）
安全不是加个防火墙就结束的事，而是从配置写下的第一行开始就要有防御意识。
