不安全。PHP 8.1.28 未修复 CVE-2024-4577，该漏洞仅在 8.1.29 及以上版本中修复；需确认实际运行的 php-cgi.exe 文件版本为 8.1.29、系统区域设置为简体中文（936）/繁体中文（950）/日文（932），且以 CGI 模式运行，同时 php.ini 中禁用 allow_url_include 等危险配置。
php -v 显示 8.1.28 就安全了吗？
不安全。PHP 8.1.28 是一个 安全发布版，但它只修复了截至 2024 年 5 月 3 日已确认的漏洞（如 CVE-2023-3823、CVE-2023-3240），CVE-2024-4577 不在其中——该漏洞直到 2024 年 6 月才公开，修复版本是 8.1.29。所以即使 php -v 输出 8.1.28，只要运行在 Windows + CGI 模式 + 中文/日文系统下，CVE-2024-4577 依然存在。
验证 php-cgi 是否仍受 CVE-2024-4577 影响
关键不是看版本号是否“新”，而是确认当前实际运行的 php-cgi.exe 是否已打上 2024 年 6 月的补丁。最直接的方式是检查二进制文件本身的修改时间与哈希值：
- 在 Windows 上定位到你 Apache 或 XAMPP 实际调用的
php-cgi.exe（不是php.exe），例如C:\xampp\php\php-cgi.exe - 右键 → “属性” → “详细信息” 标签页，查看“产品版本”字段：它应显示
8.1.29，而非8.1.28 - 若不确定，用 PowerShell 计算 SHA256：
Get-FileHash C:\xampp\php\php-cgi.exe -Algorithm SHA256
，比对官方发布的8.1.29Windows 二进制包中对应文件的哈希（见 windows.php.net/downloads/releases/） - 临时起见，可手动触发探测请求：
用 curl 发送：curl -v "http://localhost/test.php?%ad-d+allow_url_include%3d1"
，若返回 PHP 源码或 500 错误中含Failed to open stream: php://input等字样，说明补丁未生效
Apache 配置里藏着没被升级的 php-cgi
很多人升级了 PHP 主程序，却忘了更新 Web 服务器配置中硬编码的路径。尤其在 XAMPP 或自定义 Apache 部署中，ScriptAlias 或 Action 指令可能仍指向旧版目录：
- 检查
httpd.conf或httpd-xampp.conf中是否存在类似：ScriptAlias /php-cgi/ "C:/old-php-version/"或Action application/x-httpd-php-cgi "/php-cgi/php-cgi.exe" - 确认该路径下的
php-cgi.exe文件时间戳是否晚于 2024-06-07（CVE-2024-4577公开日） - 重启 Apache 后，用
ps aux | grep php-cgi（Linux）或任务管理器（Windows）确认新进程加载的是哪个路径下的二进制
补丁生效 ≠ 漏洞被彻底封死
即使 php-cgi.exe 已是 8.1.29，仍需确认运行时环境未绕过补丁逻辑：
立即学习“PHP免费学习笔记（深入）”；
- Windows 系统区域设置必须是中文（936）、繁体中文（950）或日文（932）——只有这些代码页会触发 Best-Fit 字符转换，补丁才真正起作用；若系统是英文（1252），该漏洞本就不适用，无需补丁
- PHP 必须以 CGI 模式运行（即通过 Web 服务器调用
php-cgi.exe），CLI 或 mod_php 模式不受影响 - 补丁仅拦截
-和高位字节（如0xAD）被解释为命令行选项的行为，但不会禁用allow_url_include等危险配置项——它们仍需在php.ini中显式关闭
最容易被忽略的是：补丁只修复“怎么解析参数”，不修复“参数本身是否危险”。哪怕 php-cgi 版本正确，如果 php.ini 里还开着 allow_url_include = On，攻击者换一种方式（比如直接传 ?file=http://...）仍可能触发 RFI。
