Nikto 扫一个老旧的常用 Perl 论坛，返回结果里直接标出了 /cgi-bin/printenv 可访问。漏洞这个文件本身不是检测漏洞，但它把环境变量全吐出来了——服务器路径、工具版本号、常用甚至数据库连接串的漏洞片段。渗透测试里这种信息泄露比想象中致命，检测攻击者拿到这些能省掉一半踩点时间。工具CGI 漏洞检测工具的常用核心价值就在这儿：快速定位那些不该暴露的接口和参数。

Nikto 算是漏洞最老牌的选择。命令行敲下去，检测它对着目标端口发一堆 HTTP 请求，工具检查 6700 多个潜在危险文件，常用包括常见的漏洞 CGI 脚本、备份文件、检测配置泄露。速度不算快，但覆盖面广。我习惯用它做第一轮扫描，输出里带 OSVDB 编号的条目优先看。有个坑：Nikto 的误报率不低，特别是对自定义 404 页面处理不好的服务器，得手动复核。

另一类工具走的是模糊测试路线。比如 Wfuzz，用字典爆破 CGI 路径和参数。假设目标有个 search.cgi?query=，Wfuzz 能自动替换 payload 测试 XSS 或命令注入。它的优势在灵活——你可以把字典换成针对特定 CMS 的 CGI 列表，或者用 --hc 404 过滤掉不存在的页面。实际用的时候，配合 --filter 参数按响应长度或状态码筛选，效率比手动试高太多。

还有 Nuclei，这几年用得越来越多。它基于 YAML 模板，社区维护了上千个 CGI 相关的检测规则。跑一条 nuclei -t cgi/ -u http://target，几秒钟就能把已知的 CGI 漏洞模式过一遍。模板里会写清楚请求怎么发、匹配什么特征。比如检测 php-cgi 的 CVE-2012-1823 时，模板直接构造 ?-d+allow_url_include%3d1+-d+auto_prepend_file%3dphp://input 这种参数，看响应里有没有执行结果。这种精确性比泛泛扫路径强得多。

别忽略 dirb 和 gobuster 这类目录爆破工具。它们本身不专门针对 CGI，但配上 cgi-bin 常见脚本字典——比如 test.cgi、admin.cgi、webmail.cgi——照样能挖出东西。我去年在一个客户内网里用 gobuster 扫出 /cgi-bin/.bash_history，服务器配置失误把 shell 历史文件放进了 web 目录，里面明文写着数据库密码。这种案例说明工具组合比单打独斗有效。

检测命令注入类的 CGI 漏洞，Commix 更专业。它专门针对 os command injection，能自动识别注入点、选编码方式、甚至反弹 shell。对 ping.cgi?host= 这种经典场景，Commix 会测试 ;id、|whoami、`uname -a` 各种分隔符，比手工试全得多。不过它跑起来动静大，目标有 WAF 的话容易被封 IP。

工具再全，关键还是看怎么用。我见过有人拿 Nikto 扫完没发现高危就收工，结果漏了 /cgi-bin/ 下一个需要 POST 参数才能触发的漏洞。CGI 检测得结合手动验证：扫出来的路径用浏览器或 curl 实际访问一遍，看返回内容是否包含敏感信息，参数是否可操控。工具给的是线索，不是结论。

最后提个细节。很多老 CGI 脚本用 PERL 写，处理参数时直接拼进 open() 或 system() 调用。检测这类漏洞时，nikto -C all 会尝试更多 CGI 目录，但真正定位到具体参数还得靠 Burp Suite 的主动扫描模块。Burp 的 CGI 漏洞 扫描插件能对每个参数做变异测试，虽然慢，但准确率比纯路径扫描高一个档次。

工具列表拉出来很长，实际干活时选两三个顺手的就行。Nikto 做广度，Nuclei 做精度，Commix 打命令注入，Wfuzz 补字典爆破。剩下的靠经验判断哪些响应值得深挖。CGI 这东西本身在淘汰，但遗留系统里一抓一大把，漏洞检测的需求短期内不会消失。