Nginx PHP解析漏洞本质是cgi.fix_pathinfo=1导致的路径向前递归解析：当请求/1.jpg/xxx.php时，Nginx因.php后缀转交php-cgi处理，而php-cgi发现xxx.php不存在，便逐级截断路径直至找到存在的1.jpg，并以其为脚本执行——若该图片含PHP代码（图片马），即被解析执行；修复需将php.ini中cgi.fix_pathinfo设为0，并确保php-fpm.conf中security.limit_extensions仅限.php。
不能直接用 Burp “测试” PHP 5.4.1 的 php-cgi 漏洞——它不是 Burp 内置功能，而是需要你手动构造特定请求路径来触发解析行为。 这个漏洞本质是 cgi.fix_pathinfo=1（默认开启）+ Nginx 配置不当导致的“向前解析”，Burp 只负责帮你发包、改包、观察响应，不提供自动探测逻辑。
为什么 /xxx.jpg/1.php 这种路径能触发漏洞
当 Nginx 将请求转发给 php-cgi 时，若 URI 中不存在真实文件（如 1.php），而 cgi.fix_pathinfo 开启，php-cgi 会尝试从 URI 末尾往前截取，直到找到一个“看起来像 PHP 文件”的路径段，再用它来决定脚本路径和查询字符串。例如：
- 请求
GET /uploads/test.jpg/1.php - Nginx 找不到
1.php，把整个 URI 交给 php-cgi - php-cgi 解析出 SCRIPT_FILENAME =
/var/www/html/uploads/test.jpg（真实存在的图片文件） - 但执行时仍按 PHP 解析该图片文件 → 如果图片里嵌了 PHP 代码（即“图片马”），就会被执行
所以关键不是 Burp 有多智能，而是你能不能精准构造出这个“假后缀 + 真文件”的路径，并确认目标用了 php-cgi + cgi.fix_pathinfo=1。
在 Burp 中实际怎么操作
先确保你已上传一个带 PHP 代码的图片（比如用 exiftool -Comment='<?php phpinfo(); ?>' test.jpg 生成），再通过 Burp 发送请求验证解析是否生效：
立即学习“PHP免费学习笔记（深入）”；
- 用 Proxy 抓到一个正常访问该图片的请求（如
GET /uploads/test.jpg） - 右键 →
Send to Repeater，在 Repeater 的请求行中把路径改成/uploads/test.jpg/1.php（注意不要改 Host 或其他头） - 发送，看响应：如果返回了
phpinfo()输出或报错信息（如Parse error），说明漏洞存在 - 如果返回 404 或原图二进制内容，说明未触发解析，可能原因：
cgi.fix_pathinfo=0、Nginx 未用 fastcgi_pass、或路径中没有真实存在的 .jpg 文件
容易踩的三个坑
很多人卡在这几步，不是 Burp 不好用，是没理解服务端配置依赖：
-
cgi.fix_pathinfo必须为1（PHP 默认值），但很多生产环境已手动关掉；仅靠 Burp 发包无法判断该值，需结合错误信息、phpinfo()页面或目录遍历泄露的配置文件来确认 - 路径中“假后缀”前的文件必须真实存在且可被 Web 访问（如
test.jpg要真在 uploads 目录下），否则 Nginx 层就 404 了，根本不会转发给 php-cgi - 某些 WAF 或 Nginx 规则会拦截含多个点号或斜杠的路径（如
.jpg/1.php），此时 Burp 能发出去，但请求在到达 php-cgi 前就被丢弃 —— 要看 Access Log 或用tcpdump确认流量是否真的到了 php-fpm 进程
真正难的从来不是怎么在 Burp 里点几下，而是你得知道什么时候该去翻 php.ini，什么时候该查 Nginx 的 location 块，以及为什么那个看似多余的斜杠，恰恰是绕过文件存在性检查的关键。
