PHP 5.4.1 已于2015年终止官方支持，CVE-2012-1823等漏洞无补丁可用，且PHP官方及CISA、NVD等平台均将其标记为EOL，不再接受报备或分配CVE编号。
PHP 5.4.1 的 php-cgi 漏洞异常攻击，本质上已无法“报备”——该版本早已超出所有官方支持周期，且漏洞本身（如 CVE-2012-1823、CVE-2024-4577 等）在 2024–2026 年间已被反复验证并广泛利用。厂商不会接受对 PHP 5.4.1 的漏洞报备，因为这不是一个可修复的“新问题”，而是一个已知、高危、且无补丁的废弃状态。
为什么不能向 PHP 官方或主流厂商报备这个版本的漏洞
PHP 官方自 2015 年起就终止了对 PHP 5.4 的所有支持，包括安全更新。这意味着：
-
php-cgi在 5.4.1 中存在原始 CGI 参数注入缺陷（如通过?-d allow_url_include=1 -d auto_prepend_file=php://input直接执行代码），该问题在 PHP 5.4.2+ 已部分缓解，但 5.4.1 无任何补丁可用 - 2024 年披露的
CVE-2024-4577（Windows Best-Fit 绕过）和 2026 年爆发的CVE-2026-109618/109619（php2shell）均影响 PHP 5.4+，但官方仅对仍在维护的分支（8.1/8.2/8.3）发布修复，5.4 不在修复范围内 - 所有主流安全平台（CISA、NVD、OSVDB）已将 PHP 5.4.x 标记为 “EOL（End-of-Life）”，其漏洞条目不再接收新报告，也不分配 CVE 编号
如果你正在运营含 PHP 5.4.1 的系统，必须立刻做的三件事
这不是“报备”问题，而是“止损”问题。以下操作需立即执行：
- 停止使用
php-cgi模式：检查 Web 服务器配置（如 Apache 的ScriptAlias /php-cgi/或 Nginx 的fastcgi_pass指向php-cgi二进制），全部禁用或重定向到现代 PHP-FPM 实例 - 升级或隔离：若业务逻辑强依赖 PHP 5.4，必须用容器或虚拟机做网络/进程级隔离，并严格限制出向连接、禁用
allow_url_include、auto_prepend_file、exec等函数（通过disable_functions） - 日志中若出现类似
GET /cgi-bin/php?-d+allow_url_include%3d1或QUERY_STRING=%ad的请求，说明已被扫描或攻击，应立即封禁源 IP，并检查/var/log/php-fpm.log和 Web 访问日志中是否有SCRIPT_FILENAME=/tmp/xxx.php类记录
如果必须走“报备流程”，实际能联系谁
所谓“报备”，在现实中只适用于你使用的**下游产品**，而非 PHP 本身：
立即学习“PHP免费学习笔记（深入）”；
- 若使用 XAMPP/WAMP/MAMP：联系对应发行方（如 Apache Friends），但需注意 XAMPP for Windows 默认启用
php-cgi，且其 5.4.x 版本早已停更，他们只会建议你换新版或弃用 - 若托管在虚拟主机商（如 Bluehost、阿里云虚拟主机）：提交工单时明确写清“检测到针对 PHP 5.4.1 cgi 模式的 RCE 扫描”，要求对方确认是否仍运行该版本，并关闭 CGI 接口；多数厂商会直接拒绝支持，或强制升级 PHP 运行环境
- 若集成在某 CMS（如旧版 Drupal 6 或 WordPress 3.x）：应向该 CMS 官方仓库提交 issue，但需注明“此问题根因是底层 PHP 版本过旧”，而非 CMS 自身漏洞——CMS 社区通常只维护当前支持周期内的 PHP 兼容性
真正危险的不是“如何报备”，而是还在用 PHP 5.4.1 处理外部请求。它就像开着门的保险柜，钥匙早被贴在墙上——重点不是通知厂家，而是立刻换锁、搬柜子、或者至少把柜子锁进地下室。
