CVE-2012-2311漏洞检测应直接发送GET请求/?-s，若返回PHP源码（如<?php或注释行）即受影晌；该漏洞仅在mod_cgi+php-cgi直连部署下触发，mod_php或php-fpm完全免疫，与PHP版本弱相关。
直接检测 php-cgi 是否受 CVE-2012-2311 影响，别扫版本号
PHP 5.3.11 的 php-cgi 漏洞（CVE-2012-2311）本质是 CGI 模式下对查询字符串中以 - 开头且不含 = 的请求处理异常，会导致源码泄露。它和 PHP 版本号弱相关，强依赖部署方式——只有用 mod_cgi + php-cgi 的组合才可能中招，mod_php 或 php-fpm 完全免疫。所以检测重点不是“是不是 5.3.11”，而是“当前 CGI 解释器是否响应 ?-s”。
- 最可靠方法：手动发一个
GET /index.php?-s请求，看返回是不是 PHP 源码（不是 404/500/空白页） - 自动化验证可用
curl或httpx批量探测：curl -s "http://target.com/test.php?-s" | head -n 5，观察是否有<?php或注释行 -
Versionscan这类基于 CVE 数据库比对的工具会标出“PHP 5.3.11 受影响”，但无法判断你实际是否运行在漏洞路径上，容易误报
php-cgi 检测必须绕过 Web 服务器层做直连
很多扫描器默认走 Apache/Nginx 代理，而漏洞触发前提是请求**直接抵达 php-cgi 进程**。如果目标用 Nginx + fastcgi_pass，?-s 请求会被 fastcgi 协议拦截或丢弃，永远扫不到真实状态。
- 确认是否直连
php-cgi：检查 Web 服务器配置里有没有ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/这类指向php-cgi二进制的配置 - 若确为 CGI 模式，需用
curl直接访问 CGI 脚本路径，例如：curl http://target.com/cgi-bin/php-cgi?-s（注意不是/index.php） - 某些环境
php-cgi被重命名为php5-cgi或放在非标准路径，得先通过ls /usr/bin/php*或ps aux | grep cgi确认进程名和位置
别用 ThinkPHP 或 SSRF 工具碰这个漏洞
这个漏洞和框架、序列化、SSRF 都无关，是底层 CGI 解析逻辑缺陷。所有面向应用层的工具——比如 tpscan、PHPGGC、PHP Insights、甚至 RIPS——都检测不到它。它们要么分析 PHP 代码结构，要么模拟 HTTP 请求行为，但不会去构造一个违反 CGI 规范的 query string 并观察响应体内容。
-
php-malware-finder的 YARA 规则针对的是恶意代码特征，不是协议解析缺陷 -
PHP Security Checker校验的是编译参数和补丁状态，不涉及运行时 CGI 行为 - 商用 DAST 工具（如 Burp Scanner）默认不启用
?-s类 payload，需手动加到 active scan 的 payload list 里才可能覆盖
修复后务必验证 php-cgi 是否仍可被外部调用
升级到 PHP 5.3.12+ 只是治标；更彻底的做法是禁用 CGI 模式，或在 Web 服务器层拦截危险 query string。但很多人修完以为万事大吉，却忘了检查 php-cgi 是否还暴露在公网。
立即学习“PHP免费学习笔记（深入）”；
- Apache 下用
RewriteCond %{QUERY_STRING} ^(%2d|-)[^=]+$规则后，再试?-s应该返回 403 - Nginx 下用
if ($args ~ "^(-|%2d)[^=]*$") { return 403; }，注意if在 location 块中慎用 - 最关键的验证点：确认
php-cgi二进制文件权限是否为755且不在 Web 可访问目录下（如/var/www/html/），否则攻击者可直接下载它
