客户转来一条 PHP 漏洞预警，我们把官网的版本号挨个查了一遍

客户把一张预警截图转过来，问官网会不会中招。我们没先回要不要紧，登服务器敲了一行 php -v，把手上在维护的官网版本号挨个查了一遍。查完才发现，这事不是装个补丁就完了，几个站的运行环境早该清一清了。

那位客户做本地服务，官网平时就挂个介绍和电话。看到远程代码执行几个字他慌了，问要不要先关站。我们说关站解决不了版本问题，得先看跑的是哪个 PHP。运维当天把手上的官网过了一遍：面板标签和真实版本对不上，还留着早年测试的旧站没关。

补丁比原计划早了一天，攻击比补丁更早

今年 8 月，Calif 和 Wiz 借 AI 各自发现了这个潜伏十余年的漏洞，缺陷能追到 2012 年的 PHP 5.4.0，默认配置就带风险。各方保密修了近两个月，10 月 20 日 Hacker News 上有人发帖预告，帖子删了截图已传开，PHP 安全团队当天把原定 10 月 22 日的发布提前到 10 月 21 日 14 时。攻击者没等：Cloudflare 在 7 时 43 分就监测到首批攻击，比补丁还早。CNVD、NVDB 先后发风险提示，多国临时关停政企网站；11 月 2 日芜湖市数据资源管理局把国家网络安全通报中心的预警转到地方，连该升到哪几个版本都写清了。

官网为什么首当其冲：版本号一个都不能猜

编号 CVE-2026-109618、CVE-2026-109619，代号 php2shell，出在 PHP 核心层，不是插件毛病。WordPress、Laravel 这类 CMS 都在影响范围内，我们给客户搭的 PbootCMS 站也一样，后台、上传、伪静态全跑在 PHP 上。攻击者不用登录，一个特制 POST 请求就能触发内存破坏，拿到服务器控制权限，后果是拒绝服务、数据窃取、远程代码执行。受影响区间写得很具体：8.5.x 低于 8.5.12、8.4.x 低于 8.4.27、8.3.x 低于 8.3.36、8.2.x 低于 8.2.35，8.1 及更早同样在名单里，对应修复版就是 8.5.12、8.4.27、8.3.36、8.2.35。容易踩的坑是信面板：有个站写着 7.4，敲命令一看跑的是更早分支。别猜，逐台登上去看。

当天做的六件事，照着过一遍就行

那天的动作整理成一张表，后来给客户也用这套：

• 逐台敲 php -v 记下真实版本，面板旧标签不作依据。
• 对照四个修复版升到对应安全版；8.1 及更早直接排迁移。
• 升级前整站打包、导出数据库，回退备齐再动手。
• 按非必要不上网梳理资产：后台、探针、测试站、旧演示站能关就关。
• 暂时升不了的先隔离、限访问、下线非必要系统，WAF 挡异常 POST。
• 开日志分析和监测，重点盯异常 POST 与上传，别等首页被改才发现。

通报给运营单位的建议也是这两条：排查升级，加强日志监测。升级是换锁，日志是看有没有人试过锁。

一个客户站的复盘：升级之外还有两件麻烦事

动手才知道麻烦不在升级。有个客户的官网跑在老分支上，同服务器还挂着两年前做活动的演示站，早没人用，公网却一直能开。我们先把演示站下线，才排升级窗口。那晚整站和数据库各备一份，切到 8.3.36，重启后后台一个老上传组件报错，是旧写法不兼容，改完配置才恢复。所以验收比升完就走啰嗦：上传、表单、搜索、伪静态、sitemap 挨个点一遍，确认没掉功能。这类小毛病比漏洞本身更拖时间，客户往往第二天才发现。他后来问多久查一次，把 PHP 版本、CMS 版本、备份状态放进一张表，一个月对一次，有新预警临时加一轮。

两个 CVE 看着吓人，落到中小企业官网上就是一行版本号的事。难的不是补丁，是知道自己手上跑着什么。