php -v 显示的是 cli 版本,web 请求实际运行的是 php-fpm、mod_php 或 php-cgi,三者可能版本不同;需通过 phpinfo() 确认 web 服务加载的 sapi 模块及版本,并验证是否满足 cve-2024-4577(windows+cgi+中文/日文代码页)或 cve-2026-109618/109619 的触发条件。

php -v 输出的版本号不等于实际运行版本
你用 php -v 看到的是 CLI 版本,而 Web 请求走的是 PHP-FPM、mod_php 或 php-cgi —— 三者可能完全不同。比如服务器装了多个 PHP,Apache 可能调用 /usr/bin/php-cgi,但 php -v 显示的是 /usr/local/bin/php。必须确认 Web 服务实际加载的 CGI 二进制路径和版本。
实操建议:
- 在 Web 根目录放一个
phpinfo.php,内容为<?php phpinfo(); ?>,访问后查页面顶部的PHP Version和Server API(若显示CGI/FastCGI或CGI,才算 php-cgi 场景) - 检查 Web 服务器配置:Apache 的
ScriptAlias或Action指令、Nginx 的fastcgi_pass后面是否指向php-cgi或php.exe - Windows 下尤其要查系统代码页:运行
chcp,输出936(简体中文)、950(繁体)、932(日文)才可能触发 CVE-2024-4577
PHP 8.1.28 明确受 CVE-2024-4577 影响
CVE-2024-4577 的官方影响范围写得很清楚:PHP 8.1 。你的 <code>8.1.28 就在这个区间内,只要满足「Windows + CGI 模式 + 中文/日文代码页」三个条件,就存在风险。
注意点:
- 这个漏洞只存在于 Windows 平台;Linux/macOS 下的 php-cgi 不受影响
- 不是所有 Windows 都中招:只有系统当前代码页是
936、950、932等启用 Best-Fit 转换的才会被绕过 - 即使你没显式配置 CGI,XAMPP 默认的
ScriptAlias /php-cgi/ "C:/xampp/php/"也构成暴露面
快速验证是否真能被利用
别只看版本,要测真实行为。CVE-2024-4577 的典型 POC 是构造含 %AD 编码的查询参数,触发 PHP 把它误解析成命令行选项。
你可以用 curl 测试(替换 your-domain.com/test.php):
curl -v "http://your-domain.com/test.php?%ADd+allow_url_include%3d1+%ADd+auto_prepend_file%3dphp://input" \ -H "Content-Type: application/x-www-form-urlencoded" \ --data "<?php echo 'poc_test'; ?>"
如果返回 poc_test,说明漏洞可利用;如果报 400/500 或无回显,可能是已打补丁、禁用了 CGI、或代码页不匹配。
补充提醒:
- 测试前确保目标文件
test.php存在且可访问,内容可以为空 - 部分 WAF 或 Nginx 配置会拦截含
%AD的请求,结果为 false negative - 该 POC 依赖
allow_url_include=On,默认是 Off,所以实际利用链还需配合其他条件(如已有可控文件写入)
php-cgi 漏洞和 php2shell 是两回事
你查的是 CVE-2024-4577(php-cgi),不是最近爆的 CVE-2026-109618/109619(php2shell)。后者影响所有平台、所有部署方式,且无需特定编码或代码页,只要版本低于修复线(如 8.1.28 对 php2shell 也属未修复状态)。
也就是说:
-
8.1.28在 Windows + CGI + 中文代码页下:有 CVE-2024-4577 风险 -
8.1.28在任意平台任意部署下:有 CVE-2026-109618/109619 风险(官方已停止支持,无正式补丁) - 两个漏洞的触发机制、缓解方式、危害路径完全不同,不能互相替代判断
最常被忽略的一点:很多人升级了 CLI 的 PHP,却忘了更新 Apache 或 PHP-FPM 加载的 SAPI 模块,或者用包管理器升级后没重启 php-fpm 服务——版本号看着对,实际跑的还是旧二进制。
php免费学习视频:立即使用
踏上前端学习之旅,开启通往精通之路!从前端基础到项目实战,循序渐进,一步一个脚印,迈向巅峰!











