安全影响

NGINX 承担着公共互联网中很大一部分流量的前端接入。
攻击者若能通过 HTTP 访问到存在漏洞的 NGINX 服务器，只需发送一个请求，即可导致工作进程的堆内存溢出，从而实现远程代码执行。该攻击无需身份验证、无需任何前置访问条件，也无需已有会话。写入已分配内存区域之外的数据字节来源于攻击者提供的 URI，因此内存破坏的内容由攻击者控制，而非随机。反复发送此类请求还可使工作进程不断崩溃重启，形成崩溃循环，从而降低该实例上所有服务的可用性。
该漏洞不涉及控制平面的暴露。它是请求处理路径上的一个数据平面问题。
受影响范围:
该漏洞存在于 ngx_http_rewrite_module 模块中，这是每个标准 NGINX 编译版本都包含的模块。
NGINX 开源版：0.6.27 至 1.30.0 版本
NGINX Plus：R32 至 R36 版本
NGINX Instance Manager：2.16.0 至 2.21.1 版本
F5 WAF for NGINX：5.9.0 至 5.12.1 版本
NGINX App Protect WAF：4.9.0 至 4.16.0 版本，以及 5.1.0 至 5.8.0 版本
F5 DoS for NGINX：4.8.0 版本
NGINX App Protect DoS：4.3.0 至 4.7.0 版本
NGINX Gateway Fabric：1.3.0 至 1.6.2 版本，以及 2.0.0 至 2.5.1 版本
NGINX Ingress Controller：3.5.0 至 3.7.2 版本，4.0.0 至 4.0.1 版本，以及 5.0.0 至 5.4.1 版本
以下产品不受影响：F5 Distributed Cloud、F5 Silverline、NGINX One Console、BIG-IP、BIG-IQ、F5OS、Traffix SDC 及 F5 AI Gateway。完整评估请参阅 F5 的安全公告。

为什么你不用过分担忧

对于个人站点（主要为博客）的Nginx使用场景，常见的是作为WordPress和Typecho 以及其他杂七杂八的CMS的前端代理，涉及重写的部分就是伪静态。目前WordPress和Typecho 流行的伪静态写法都使用try_files 均不符合漏洞触发条件，所以没必要太担忧。如果你仍然在使用老掉牙的rewrite，那么最好问问DeepSeek自己的规则要不要优化一下了。
我查找了一些古典的Typecho伪静态写法：

#写法1
location / {
    index index.html index.php;

    if (-f $request_filename/index.html) {
        rewrite (.*) $1/index.html break;
    }

    if (-f $request_filename/index.php) {
        rewrite (.*) $1/index.php;
    }

    if (!-f $request_filename) {
        rewrite (.*) /index.php;
    }
}
#写法2
if (!-e $request_filename) {
    rewrite ^(.*)$ /index.php$1 last;
}

这俩本身看着就不安全，但是仍然没用？实际不符合本次的漏洞触发条件。不过也确实很有必要换一下了。

标签：无

你的评论