2024年6月，危漏PHP官方紧急发布了一个补丁，危漏修复CVE-2024-4577。危漏这个漏洞影响所有在Windows平台上运行的危漏PHP，只要用了CGI模式，危漏攻击者就能在服务器上执行任意代码。危漏听起来像老生常谈？危漏但这次不一样——它绕过了之前所有针对CVE-2012-1823的防护措施。

我拿一个实际案例来说。危漏某电商后台用的危漏就是Windows Server + PHP 8.1，打了之前所有的危漏补丁。攻击者只发了一个URL编码的危漏请求，参数里塞了软连字符（%AD），危漏PHP就把这个字符当成了普通连字符处理，危漏结果命令行参数被注入，危漏直接弹了个shell。危漏整个过程不到两秒，日志里只留下一条200响应。

为什么这个漏洞特别麻烦

PHP的CGI模式本身就有历史包袱。当年CVE-2012-1823是因为查询字符串里的“-d”参数能被当成php.ini指令用，后来官方加了过滤。但Windows的Best-Fit字符映射机制成了新漏洞的跳板。简单说，PHP在Windows上处理某些特殊字符时，会做一次“最佳匹配”转换，比如把%AD转成“-”。攻击者就利用这个转换，把恶意参数伪装成普通字符，绕过了过滤逻辑。

我翻过PHP的源码，问题出在php_cgi.c里对命令行参数的解析。它依赖Windows的WideCharToMultiByte函数做编码转换，但没考虑到某些Unicode字符会被映射成ASCII里的危险符号。这不是PHP独有的问题，但PHP的CGI模式把它放大了——因为CGI直接把HTTP请求转成了命令行参数。

哪些场景最危险

不是所有PHP安装都受影响。Linux下的PHP-CGI没这个问题，因为字符映射行为不同。但Windows上，只要你用了这些组合：Apache + PHP-CGI、IIS + PHP-CGI，或者任何把PHP当作CGI解释器调用的Web服务器，就中招。Nginx + PHP-FPM没事，因为FPM不走命令行参数传递。

我见过一个奇葩配置：某公司为了兼容老系统，在Windows上跑了PHP 5.6，还开了CGI模式。他们以为PHP 5.6太老没人攻击，结果漏洞公开第二天就被扫了。攻击者没留后门，只是把首页改成了黑页——纯粹为了炫技。

怎么防

最直接的办法：别用CGI模式。能换FPM就换FPM，能换Linux就换Linux。如果实在换不了，打补丁。PHP 8.1.29、8.2.20、8.3.8都修了。但注意，补丁只修复了已知的字符映射组合，不排除还有其他Unicode字符能绕过。

临时缓解方案也有：在Web服务器层面拦截包含%AD的请求。Apache可以用RewriteRule，Nginx用if ($args ~* "%AD") { return 403; }。但这只是权宜之计，因为攻击者可以换其他编码。

我自己的做法更粗暴：把所有Windows上的PHP-CGI进程全停了，改成FastCGI。改配置花了半小时，但省了以后半夜起来应急的麻烦。顺便说一句，PHP官方文档里关于CGI模式的警告已经挂了十几年，但总有人图省事直接开。

一个容易被忽略的细节

这个漏洞的PoC在网上传得很快，但很多人没注意：攻击需要知道目标PHP的安装路径吗？不需要。攻击者可以盲打，因为命令行参数注入后，PHP会尝试执行任意代码——哪怕路径不对，错误信息里也会泄露路径。我测试时用了一个不存在的路径，结果PHP返回了“Could not open input file”，里面包含了完整的php.exe位置。

更糟的是，如果服务器开了display_errors，攻击者甚至能看到php.ini的加载路径。这等于把内网结构暴露了一半。

所以，别以为打了补丁就万事大吉。检查你的日志里有没有包含%AD或%ad的请求，尤其是那些返回200但URL很奇怪的记录。我上周帮一个客户排查，发现攻击者已经用这个漏洞跑了三天的whoami命令，只是没做进一步动作——可能是在踩点。

PHP的高危漏洞年年有，但CGI模式相关的总是特别致命。因为它把Web请求和系统命令之间的墙拆了。下次你看到“PHP-CGI”这几个字，最好多留个心眼。

(责任编辑：焦点)