登录
北京时间 10 月 21 日晚上 10 点，PHP 官方紧急发了四个版本：8.5.12、8.4.27、8.3.36、8.2.35。修的是两个未登录就能远程执行代码的漏洞，CVE-2026-109618 和 CVE-2026-109619，合称 PHP2Shell。官方按 CVSS v4.0 打 9.2。NVD 列的受影响范围最低到 5.4.0，8.2 到 8.5 各有官方修复版；7.4 和更老的版本，得另找出路。PHP 官网The Hacker News
披露后，一些网站干脆临时下线。漏洞长在解释器里，不在插件或框架里，业务代码写得再干净也挡不住。官方也说，只有升级才是完整方案。可对跑着老 PHP 的站来说，“升级”两个字背后，可能是一套没人敢碰的系统。The Hacker NewsPHP 官网
于是问题变成：没补丁，是不是只能关站？
不一定。但你得先回答一个比版本号更重要的问题：这台机器上的 PHP，是谁装的，谁在维护？
同一个 7.4，两种命运
“PHP 7.4 没补丁”这句话，只在“等官方出新版本”这个前提下成立。官方确实只给 8.2 到 8.5 出修复版；7.4、8.0、8.1 只留了最小源码回移植分支，7.3 及更早完全没有。但 Linux 发行版和 LTS 厂商是另一条线。PHP 官网
Ubuntu 的安全通告里，20.04 的 PHP 7.4 修复包是 7.4.3-4ubuntu2.29+esm5，18.04 的 PHP 7.2 也有带 esm 后缀的修复包——前提是你还在 Ubuntu Pro 的扩展安全维护里。Red Hat 同样如此：RHEL 8 的 PHP 7.4 软件流发了 RHSA-2026:87080，RHEL 9 的 PHP 8.0.30 发了 RHSA-2026:87151。按上游口径，这两个版本早就停止支持了。Ubuntu
反过来，Debian 11 的 PHP 7.4 这次没出现在 Debian 安全团队的修复列表里。原因不在 PHP，而在 Debian 11 的 LTS 已经在 2026 年 8 月 31 日结束。同样是 PHP 7.4，装在 Ubuntu 20.04 上可能有补丁，装在 Debian 11 上可能没有。版本号相同，命运不同。Debian
所以第一步不是决定关不关站，而是查清楚：你的 PHP 来自哪个包、哪个仓库、哪个主机面板，那个来源还在不在发安全更新。别只看 `php -v`：发行版修复常常保持上游版本号，只在包版本后加后缀，7.4.3 这个数字说明不了 CVE 有没有修。去看包管理器的 changelog 里有没有 CVE-2026-109618 和 CVE-2026-109619，或者直接查发行版的 CVE 跟踪页。
补丁找不到，再谈关站
如果查完发现，你的 PHP 既没有上游补丁，也没有发行版或厂商补丁，那才进入“遗留系统”的真正难题。
能隔离就先隔离。把 PHP 服务从公网拿下来，放到 VPN、白名单或边缘认证后面；确认攻击者不能绕过代理直接打到源站。
官方给了一组临时缓解措施。先切断可控的内存耗尽路径：把 memory_limit 设为 -1，并确认应用改不回来；再把 post_max_size 压到业务真正需要的水平，并在 Web 服务器或代理层限制请求体大小、字段数、multipart 分片数。然后处理另一个入口：在 php.ini 或 FPM 池配置里关掉 session.upload_progress.enabled，重启所有 worker；PHP 8.5 上再把 fatal_error_backtraces 设为 0。
官方明确说：这些措施只降低特定攻击路径的暴露面，不等于安全。而且 memory_limit=-1 会把内存耗尽的 DoS 风险交给容器或 cgroup 去兜，不是白拿的。PHP 官网
能升就升。7.4、8.0、8.1 有官方最小源码回移植分支，适合还能从源码构建的团队；扩展和业务代码要不要动，得在测试环境验。7.3 及更早没有官方补丁，硬移植的冲突和风险通常高过收益，更现实的是先落到 7.4 或 8.1 这类还有官方回移植的版本，再排期往 8.3 或 8.4 走。升级前留好回滚镜像或旧模块，逐站比对升级前后的状态码和关键业务。
既补不了也隔离不了，就关。这不是失败，是把不确定的被攻破风险，换成确定的停机损失。但关要关对地方：不是把首页换成 404，后台、管理端口、定时任务、API 都还活着。真正要关的是那个用 PHP 处理 HTTP 请求的进程，或者至少把它从可达的网络里摘出去。一个静态维护页可以留着，PHP 服务不必留。
老 PHP 不只在网站里
安全公司 Dream 披露的入侵里，攻击者拿到 25 台服务器的 root，入口不是某个公众网站，而是防火墙的管理界面——里面跑着 PHP 8.0.30。攻击者先扫了约 1.9 万台暴露在公网的防火墙管理口，筛出 240 个目标，最后打穿 25 台，还顺着管理口去打 Active Directory。The Hacker News
这提醒我们：老 PHP 不只活在网站目录里。它还藏在防火墙、NAS、监控平台、主机面板和内部工具里。你关掉官网，不等于关掉这些管理界面。盘点的时候，别只问“我有哪些网站”，要问“哪些进程在用 PHP 接 HTTP 请求，谁能让它从网络上够得着”。
风险也不是均匀分布的。Red Hat 评估说，标准 PHP-FPM 部署里，worker 会在早期初始化失败时退出，利用难度不低。Sophos 也看到大量攻击尝试没能得手。但另一边，CISA 已经把这两个洞列入 KEV。联邦机构被要求在 10 月 29 日前完成修复；真实入侵里，也有人拿到了 25 台机器的 root。对单个站点，赌概率不是策略。Red HatThe Hacker News
8.2 也快到期了
最后说个不轻松的事实：四个修复版里最老的 8.2，安全支持也只到 2026 年 12 月 31 日。不到两个月后，8.2 也会掉出官方支持列表。如果这次只是把 7.4 临时升到 8.2，然后继续放着不管，下一次漏洞来的时候，你还会问同样的问题。
遗留系统的真正定义，不是版本号老，而是没有人能说清楚它下一次谁来修。补丁可以买时间，隔离可以降风险，关站可以止损，但只有“有人负责、有升级路径、有验证流程”才能结束这个循环。
所以，老 PHP 没补丁，不一定只能关站。但如果你的系统既没有补丁，也没有人能为它做决定，那关站可能不是最坏的选择——最坏的是假装它还有补丁。
