Nginx 本身不算“中间件”——它更像一个入口层。间件但大家习惯把它归到中间件里聊，易出那我们就按这个语境来。漏洞直接说结论：Nginx 的间件高危漏洞，八成以上不是易出它核心代码写崩了，而是漏洞配置写崩了，或者第三方模块拖了后腿。间件剩下两成，易出才是漏洞 C 语言层面的内存问题。

先看一个真实案例。间件2021 年爆出的易出 CVE-2021-23017，DNS 解析器里的漏洞一个 off-by-one。攻击者控制一个恶意 DNS 服务器，间件就能触发 1 字节的易出堆溢出。1 字节，漏洞听起来像开玩笑，但配合内存布局，能搞出远程代码执行。影响范围是 0.6.18 到 1.20.0。这个漏洞的根因不在 HTTP 处理，而在 resolver 模块。很多人部署 Nginx 时压根没配 resolver，觉得自己安全。可一旦用了 proxy_pass 里的域名，或者 upstream 里写域名，resolver 就跑起来了。你以为你没用，其实你用了。

另一个经典是 CVE-2019-9511，叫“数据滴漏”。HTTP/2 的窗口更新机制被玩坏了。攻击者发一堆小窗口更新，让服务器一直分配内存，最后 OOM。Nginx 在 1.16.1 和 1.17.3 里修了。这个漏洞有意思的地方是，它不靠溢出，靠逻辑。你代码写得再规范，协议实现有缺陷，照样被打穿。那段时间 Cloudflare、Google 都中招，不是他们不专业，是 HTTP/2 太新，实现细节没吃透。

配置层面的漏洞更常见。比如 alias 目录穿越。很多人写：

location /img {  alias /var/www/images/; } 

如果 location 没加斜杠，而访问的是 /img../etc/passwd，Nginx 会把路径拼成 /var/www/images/../etc/passwd，也就是 /var/www/etc/passwd。再往上跳，就能读到系统文件。这不是 Nginx 的 bug，是 alias 和 location 的匹配规则没对齐。官方文档写得清楚，但配错的人一抓一大把。我见过一个生产环境，运维图省事，用 alias 做静态资源映射，结果整个 /etc 目录可读。扫描器一跑，直接高危。

还有 CRLF 注入。Nginx 本身对响应头做了过滤，但如果你用 add_header 或者 return 拼接了用户输入，比如：

location /redirect {  return 302 https://$arg_url; } 

攻击者传 url=%0d%0aSet-Cookie:admin=1，就能往响应里插头。虽然现代 Nginx 版本会拒绝非法字符，但老版本或者某些模块（比如 lua-nginx-module）里，这个坑还在。Lua 里用 ngx.header 赋值，如果不做校验，一样中招。

第三方模块是重灾区。比如 ngx_lua 的 ngx.req.get_uri_args，默认最多解析 100 个参数，超了返回 nil。有人不判断，直接 args.foo，就崩了。还有 ngx.escape_uri 在特定版本下对 %00 处理不当，导致路径截断。这些不是 Nginx 官方模块，但装的人多，出了问题就赖 Nginx。实际上，模块作者的水平参差不齐，有的连基本的边界检查都不做。

再说一个容易被忽略的：merge_slashes 默认是 on。但如果你关了它，//etc/passwd 和 /etc/passwd 就是两个路径。某些后端（比如 PHP-FPM）会把 // 当普通路径处理，结果绕过 location 匹配。这种漏洞在 CTF 里常见，实战里也有。我见过一个 API 网关，用 Nginx 做路由，关了 merge_slashes 为了兼容旧客户端，结果 /api//admin 直接绕过了 /api/admin 的鉴权。

Nginx 的漏洞，核心就两类：内存安全（CVE-2021-23017 这种）和逻辑/配置错误（alias、CRLF、merge_slashes）。前者靠升级，后者靠脑子。很多人装完 Nginx 就扔那了，配置文件几年不改，模块随便加。出事了怪 Nginx，Nginx 挺冤的。它只是个工具，工具不会自己写错配置。

最后提一句：别迷信“最新版就安全”。CVE-2021-23017 在 1.20.0 里还有，1.20.1 才修。升级要跟，但配置审计更重要。一个配错的 alias，比一个未修复的 RCE 更容易被利用。因为扫描器扫 alias 穿越，一抓一个准，不需要写 exploit。