10 月 21 日，PHP 官方发布安全公告，修复两个可导致未认证远程代码执行的漏洞（CVE-2026-109618、CVE-2026-109619，业内称 PHP2Shell，CVSS 9.2）。攻击者不需要账号，发一个请求就可能接管 Web 服务器。[1]
官方修复版本是 8.5.12、8.4.27、8.3.36、8.2.35。但大量线上系统跑的并不是这几个版本：PHP 7.4 在 2022 年底已停止维护，更早的 7.0、7.2 仍运行在不少多年前上线的业务系统里。
公告发布后，风远科技技术团队第一时间启动应急，约 35 小时内完成了 7 台生产服务器的修复。这篇文章介绍我们针对不同 PHP 环境的处置方法，以及这次响应是怎么做的。
一、为什么必须第一时间响应
三件事叠在一起，让这次漏洞的处置窗口比以往短得多：
- **覆盖面大。**PHP 是约 69.7% 已知服务端语言网站的后端语言。[2] PHP-FPM、Apache mod_php、php-cgi 等对外提供 Web 服务的运行方式都在风险范围内，官方认为 mod_php 风险最高：恶意请求可以在任何业务代码执行之前触发攻击。[1]
- **提前泄露，攻击先于补丁。**漏洞原定 10 月 22 日披露，10 月 20 日编号提前在网上泄露，PHP 团队把补丁提前一天发布；补丁发布之前，安全厂商已观测到针对性的攻击尝试。[3]
- **AI 让"发现"变快了。**据公开报道，这次的漏洞之一由安全公司借助 AI 模型发现，另有安全团队独立发现并上报。[4] 漏洞挖掘的成本在下降，老系统里"多年没人发现"的问题，被发现的速度会越来越快。
"补丁出来后排个期"的节奏，已经跟不上了。
二、老 PHP 环境难在哪
老系统修漏洞，难点很少在补丁本身，而在环境：
- **版本停更，没有正式修复版。**官方明确 8.1 及更早版本不再获得更新。考虑到漏洞严重性，安全团队为 7.4、8.0、8.1 提供了"最小化源码回移植"分支，但不是正式发布版本，要自己从源码编译。[1] 7.3 及更早版本连这个分支都没有。
- **业务代码不能随便动。**老系统依赖的框架版本往往较旧，直接升到 PHP 8 会大面积报错。升级语言版本等于一次重构，不是应急动作。
- **扩展和环境跨度大。**swoole、mongodb、redis、grpc 等扩展版本跨了好几代；部分底层操作系统已停止支持，软件源下架；更老的服务器内核过旧，连 Docker 都装不了，PHP 直接以模块形式跑在宿主机的 Apache 里。
所以没有一套方案能通吃，必须按场景处置。
三、我们怎么按场景处置
我们把线上环境按"PHP 版本 × 运行方式"分成几类，每类用改动最小、可回滚的方式修复。
场景一：Docker 容器里的 PHP 7.4——只重编内核，扩展不动
我们运维的大部分线上环境基于自建的 PHP 7.4 Docker 镜像。核对官方 7.4 回移植补丁后确认：补丁只新增函数，不改数据结构，扩展接口版本不变。因此可以只重编 PHP 内核，所有扩展原样保留，业务代码一行不改。
补丁版镜像在 x86 和 ARM 两种架构上分别构建，用 Nginx + PHP-FPM 和 Apache 两套环境做 HTTP 测试：普通请求、文件上传、Session、内存超限，以及 50 个并发混合请求，全部通过后才推送。旧镜像先备份为独立标签，出问题一条命令即可回滚。
镜像里还默认关闭了 session.upload_progress，这是官方确认的利用入口之一。10 月 23 日 PHP 官方又发布通告，建议在下个版本前关闭这一配置，以防另一个 RCE 路径[1]，提前关掉的配置正好覆盖了这个新风险。
场景二：版本更老、扩展更旧的容器——以原镜像为底座升级
部分服务器的镜像是几年前的老版本，例如 PHP 7.4.5 搭配 swoole 和多年前的扩展。直接换成标准镜像，扩展会跨好几代，业务风险大。我们改为以这台机器自己的镜像为底座，把内核升到 7.4.33 并打上补丁，扩展原样保留。PHP 7.3 的容器环境则直接换成补丁版 7.4.33 镜像。
场景三：PHP 8.x——升到官方修复版
PHP 8 镜像升级到官方修复版 8.3.36，扩展版本锁定，双架构验证后推送。
场景四：跑不了 Docker 的老服务器——宿主机编译同一版本，并存切换
有的服务器操作系统停留在多年前的版本，内核过旧装不了 Docker，Apache 直接加载 7.0 或 7.2 的 mod_php。这两个版本官方都没有补丁。
我们的做法是：在宿主机上用源码编译和容器镜像同一个版本的 PHP（7.4.33 + 官方补丁），装到独立目录，与旧版并存；只把 Apache 加载的 PHP 模块切过去，平滑重启。回滚就是把模块切回旧版，秒级完成。切换前事先核对了业务代码的框架版本，确认兼容 PHP 7.4。
这样，容器环境和宿主机环境的 PHP 收敛到同一个版本，以后维护只需要盯一个版本。
场景五：没有补丁的版本——不硬移植，升到有补丁的版本
对 7.3 及更早版本，也可以考虑把 7.4 的补丁硬移植过去。我们评估过 7.2：补丁涉及 17 个文件，其中 9 个有冲突，自行移植的风险高于收益。更稳妥的做法是升到已有补丁的 7.4，前提是先确认业务代码兼容；长期无人访问的老站点，确认后直接下线。
场景六：命令行常驻进程——先缩小改动面
漏洞出在 Web 请求的解析环节，队列、swoole 等不接收 HTTP 请求的命令行进程不在本次攻击路径上。应急阶段先不动它们，把改动集中在真正暴露的环节，后续再单独排期升级。
四、我们怎么第一时间响应
时间线
- 10 月 21 日晚：PHP 官方发布安全公告和补丁。
- 10 月 22 日下午：团队启动评估，确认 7.4 回移植补丁不改扩展接口，确定"只重编内核"的方案。
- 10 月 22 日晚：补丁版 PHP 7.4 镜像完成双架构构建、测试并推送，容器化的生产服务器逐台完成升级。
- 10 月 23 日中午：PHP 8 镜像升级到 8.3.36 并推送。
- 10 月 23 日晚至 24 日凌晨：在业务低峰时段，完成跑不了 Docker 的老服务器的宿主机升级。
从启动评估到全部完成约 35 小时，覆盖 7 台生产服务器，逐一比对了近 300 个站点域名升级前后的状态。
每台服务器都按同一套流程操作
确认版本与扩展 → 保留回滚镜像或旧模块 → 重建容器或切换模块 → 逐站对比升级前后的 HTTP 状态码 → 检查队列与常驻进程
几条原则贯穿始终：
- **改动最小化。**能只换内核就不动扩展，能不改业务代码就不改。目标是"漏洞堵上、业务照常"，而不是借机来一次大升级。
- **每一步可回滚、可验证。**旧镜像、旧模块、旧配置都留了备份；验收看逐站状态码和补丁特征，不看"命令跑成功了"。打补丁后的 7.4 仍显示 7.4.33，所以我们用补丁特征来确认是否已修复。
- **行为变化提前告知。**验证中我们观测到，打补丁后 PHP 内存超限时工作进程会直接退出，Nginx 返回 502，原来是返回 200 加错误页面。这类变化在上线前就同步给业务负责人。
- **生产操作选在低峰。**宿主机切换采用平滑重启，需要完整重启的放在凌晨低峰进行。
这次处置由工程师主导，AI 编程智能体承担了构建、批量比对和排障中的大量机械工作，涉及生产的每一步操作前都由负责人确认。AI 让应急响应更快，但"先确认、再动手、留退路"的流程不能省。
五、给手里有老 PHP 系统的企业
- 先盘点资产：哪些服务器、哪些容器、哪个 PHP 版本、哪种运行方式（mod_php 优先处理）、承载哪些站点。
- 按场景对号入座：有修复版的立即升；有回移植分支的重编；跑不了容器的在宿主机编译并存切换；没有补丁的升到有补丁的版本，或下线。
- 验收看补丁特征和业务状态，不看版本号；同时告知业务方可能的行为变化。
- 借这次做一次老系统体检：停更的语言版本、停更的操作系统，迟早还会遇到下一次。
风远科技自 2014 年起为企业做软件定制与运维，历经 1000+ 项目。如果你的老系统需要做漏洞排查、补丁重编或升级规划，欢迎联系风远科技，告诉我们现有环境，我们给出初步处置建议。
资讯来源与数据说明
- [1] PHP 官方：2026 年新闻与安全公告（2026-10-21 PHP2Shell 公告、2026-10-23 session 通告）
- [2] Infosecurity Magazine：Critical PHP Vulnerabilities Leaked（69.7% 为 W3Techs 口径，统计范围为服务端语言已知的网站）
- [3] BleepingComputer：PHP ships emergency patches for critical PHP2Shell flaws；SecurityWeek：PHP2Shell patches land as first exploitation attempts hit sensors
- [4] OfficeChai：OpenAI’s GPT-5.6 Sol Helped Flag The Critical PHP Bug（引述 OpenAI 博客，另有 Wiz 独立发现并上报）
处置过程来自风远科技 2026 年 10 月 22 日至 24 日的实际应急记录；内存超限行为变化为我们在验证阶段的观测结果。本文为处置思路分享，不构成对任何系统安全性的保证。