科技资讯
很多团队在这次事件里出错的地方，是「升级完成」不等于「风险关闭」这个认知差。PHP 在 10 月 21 日发布紧急更新，修复两个位于请求生命周期中的内存安全缺陷，可导致未经身份验证的远程代码执行，编号 CVE-2026-109618 与 CVE-2026-109619，CVSS v4.0 评分 9.2，社区把它们合称 php2shell【1】。受影响范围并非某个小版本，而是自 PHP 5.4 起所有未打补丁的发行版本【1】。
官方公告在处置口径上非常直接：
不存在完整的缓解措施；更新是唯一安全的选择。【1】
这句话值得单独拎出来，因为它否定了大量团队默认的第一反应——先加规则、先观察、等窗口期再升级。
图：来源页面配图（已本地备份）。引用：【1】PHP 修复了两处已遭到攻击的严重远程代码执行漏洞 — https://www.infoq.cn/article/qUEjcWbwOj5RO59250Lu?utm_source=rss&utm_medium=article
图：示意图（AI 生成，非原文截图；模型 nano-banana-2）。仅作阅读辅助，事实以正文与参考文献为准。
先看清一件事：这次没有人替你把时间挡住
把时间线摊开，会发现问题不在漏洞本身，而在「等待通知」这条路径的失效：攻击侧的可疑利用尝试最早可追溯到 10 月 17 日；Cloudflare 在补丁正式发布前约 9 小时就上线了 WAF 规则；而披露侧，CVE 编号提前两天开始流传，一名研究者误将概念验证演示视频公开发布，Chainguard 则单方面释出了包含修复的构建镜像【1】【2】。
对企业的直接含义是：当你的托管商、面板厂商、外包服务商还没发通知时，攻击者已经在研究二进制形式的修复差异【1】。Slack 群等通知，在这次事件里不是稳妥，而是空窗。
下文清单按四关排列，可以直接当作应急会议的分工表。见下文配图（漏洞处置四关流程示意）。
第一关：先确认「有没有」——资产可见性
1）盘点藏起来的 PHP。 原因很实际：PHP 大量存在于软路由固件、NAS 面板、协同办公套件与各类容器镜像中，社区讨论里被点名的就有 OPNsense、OpenMediaVault、Nextcloud 和 Coolify；而容器化让「这台机器到底跑什么运行时」变得不可见【1】。行动：用镜像清单、SBOM、进程与端口指纹三条线索交叉比对，产出一张表——谁在跑 PHP、哪种 SAPI、是否对公网开放。没有这张表，后面所有判断都是猜。
2）按 SAPI 类型和暴露面排队。 官方措辞相当克制：mod_php 两种漏洞都已通过针对默认 PHP 输入与内存限制的 HTTP 攻击验证；PHP-FPM 已确认会话生命周期漏洞可被利用，但内存不足漏洞尚无完整的 FPM 利用方式实证；FrankenPHP 仅依据源码分析被列为可能存在漏洞【1】【2】。行动：公网 mod_php 资产排第一批，内网与 FPM 资产排第二批——但「暂未实证」只是排序理由，不是免修理由。
3）把上游拉进你的清单。 如果站点跑在共享主机、托管面板或第三方运维手里，你无法直接验证补丁状态。行动：以书面形式向托管方索取「补丁版本号 + 工作进程重启时间 + 是否曾暴露于可疑流量」三项凭证，并确认对方是否具备自行构建镜像的能力。据公开报道，本次补丁分发链条一度相当混乱，把关键系统的重建能力完全外包，是把风险敞口外包【1】。
第二关：再确认「修没修」——生效验证
4）版本核对交给包管理器，不要交给 php -v。 发行版普遍采用回溯移植，主干版本号保持不变：Ubuntu 24.04 的修复包版本为 8.3.6-0ubuntu0.24.04.13，但运行时仍显示 8.3.6【1】。行动：用 dpkg -l、rpm -q 或发行版安全追踪器比对完整包版本，官方修复版本为 8.5.12、8.4.27、8.3.36、8.2.35【1】；自编译环境直接核对构建 commit。
5）升级后必须重启工作进程。 命令行不是 Web 服务器。FPM 与 Apache 的常驻 worker 会把旧引擎留在内存里，文件换了进程没换，等于没修——两份安全公告都专门提示更新后重启所有工作进程【1】。行动：把 reload/restart 写进变更脚本，重启后抽查 worker 启动时间，确认是新进程。
6）容器与 CI 基线同步重建。 只改运行中容器的文件层，下一次发布就会被旧镜像覆盖回漏洞版本。行动：更新基础镜像 tag 与 CI 构建基线，重新构建并固定摘要；同时保留一套可回滚的上一版本，避免升级引发业务故障时手忙脚乱。据公开报道，已有团队放弃公共镜像、直接按合并后的 Dockerfile 自行构建，8 分钟完成【1】——这条路值得提前演练一次。
7）WAF 是止血带，不是补丁。 Cloudflare 提前约 9 小时部署规则确实争取了窗口【1】，但规则只看得见经过它的流量。行动：同步排查源站是否允许直连、是否有 IP 白名单旁路、内网互访是否绕开防护；补丁生效后再回收临时规则，避免规则长期存在造成虚假安全感。
第三关：最后确认「有没有被踩过」——入侵排查
8）把日志回溯窗口前移到 10 月 17 日。 Amazon Threat Intelligence 在遥测数据中发现可追溯至该日的利用尝试，并建议客户至少从该日起展开调查【1】【2】。行动：拉取该日起的 Web 访问日志，重点看畸形 POST、上传目录新增文件、PHP 进程异常外连；对上传目录做一次全量文件哈希比对，重点排查一句话木马类文件。这一步建议交由有取证经验的人做，避免边查边破坏现场。
9）不要在办公终端上跑 GitHub 上的 PoC。 社区已记录到以恶作剧形式传播的伪造 PoC，其中一个的效果仅仅是修改受害者桌面壁纸；同时也存在携带恶意代码的仓库【1】。此外，已公开的利用代码对采用默认配置的 PHP 安装并不生效【1】。行动：任何验证只在隔离网段进行，禁止在生产网段执行；优先采用官方公告与可信厂商的检测方式。
10）给尚未修复的第三个漏洞配兜底配置。 CVE-2026-115560 目前仍未修复，基金会建议在下一个 bug 修复版本发布前将 session.upload_progress.enabled 设为 0【1】。行动：确认业务是否依赖上传进度条，不依赖则立即关闭；把它登记为「临时配置债」，下一版本发布后回滚并复核，防止临时措施沉淀为永久状态。
第四关：把它变成机制，而不是一次加班
11）把 EOL 日期写进排期表。 PHP 8.1 及更早版本已不在项目支持范围内，8.2 的支持将在 2026 年 12 月 31 日终止【1】。本次基金会为 7.4、8.0、8.1 发布了最基础的追溯补丁，但那属于例外而非常态【1】。行动：梳理各站点框架与扩展对目标版本的兼容性，倒排升级窗口；确实升不动的老系统，明确网络隔离与补偿性控制，并指定责任人定期复核。
12）按暴露面分级，别一刀切下线。 荷兰国家网络安全中心与荷兰众议院出于预防把网站下线，而 Sansec 则告知商家没有必要这样做【1】【2】——同一个漏洞，不同暴露面下结论可以完全相反。行动：用「是否公网暴露 + SAPI 类型 + 补丁是否生效 + 是否有可疑流量」四个维度分级，提前写好「观察 / 加固 / 临时下线」的触发条件与对外话术，避免临场拍脑袋。
古令乐编辑判断：把 72 小时拆成三段
第一段（0–6 小时）：完成资产表与 SAPI 分类，公网 mod_php 先修，WAF 规则上线并确认源站没有直连旁路。第二段（6–72 小时）：完成全部升级与 worker 重启，用包管理器逐个复核版本，同步跑完 10 月 17 日以来的日志回溯。第三段（30 天内）：处理 EOL 排期与配置债，做一次「基础镜像自行重建」演练。
还有一点常被忽略：据公开报道，PHP 基金会坦言其安全工作仍依赖一小群由基金会资助的开发者，且人数偏少【1】。开源组件的安全窗口，最终还是要由使用方自己兜底——这句话对所有技术栈都成立，不只是 PHP。
参考文献
【1】PHP 修复了两处已遭到攻击的严重远程代码执行漏洞 — https://www.infoq.cn/article/qUEjcWbwOj5RO59250Lu?utm_source=rss&utm_medium=article 【1】PHP 修复了两处已遭到攻击的严重远程代码执行漏洞 — https://www.infoq.cn/article/qUEjcWbwOj5RO59250Lu
【2】PHP Patches Two Critical RCE Vulnerabilities Already Under Attack（InfoQ 英文原文；编辑注：本文基于该来源与中文版的二次解读）— https://www.infoq.com/news/2026/10/php-critical-rce-patches/
