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 < 8.1.29。你的 8.1.28 就在这个区间内，只要满足「Windows + CGI 模式 + 中文/日文代码页」三个条件，就存在风险。
注意点：
立即学习“PHP免费学习笔记（深入）”；
- 这个漏洞只存在于 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 服务——版本号看着对，实际跑的还是旧二进制。
