2026年10月21日晚（北京时间），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（Critical），官方公告明确风险涉及处理Web请求的PHP安装，包括FPM、mod_php、php-cgi等，其中mod_php风险最高。对开发者来说，真正的问题不是"要不要升"——而是怎么升才不掉坑：EOL分支没有官方修复、Docker重建链路容易被漏掉、改ini和挂WAF都只是权宜之计，而且补丁公开前后，真实攻击已经出现。新智元知乎
两个洞：一个卡在内存耗尽，一个卡在跨请求残留
CVE-2026-109618的本质是"半成品数据被当作有效记录"：PHP在新增记录时计数先加、内存后申请，一旦申请内存时额度恰好耗尽，程序跳去报错清理，那条没填完的记录就被当成完整数据使用。官方公告将其归纳为与内存不足时的异常中断有关：部分请求数据尚未完成初始化，执行流程即被中断，后续清理可能错误处理无效内存状态。在披露的一条攻击路径中，不到8MiB的请求数据就能把PHP默认128MiB的内存额度撑爆，攻击者借这种"小请求放大内存占用"的方式精确控制程序出错的位置，最终可被利用到执行任意代码。CVE-2026-109619则是一个跨请求的释放后使用（UAF）：一次请求异常结束后内存已释放，工作进程却仍留着旧地址，下一次请求在正常初始化前读取了失效内存；它藏在记录文件上传进度的代码里，是当前最容易触发的入口。一位安全从业者对照官方公告的解读是：改ini配置只是权宜之计，其实还有可能有对应的RCE触发点没有被发现，Session Upload Progress只是最容易触发的。360漏洞研究院新智元微博
360漏洞研究院已稳定复现两枚漏洞导致的进程崩溃（SIGSEGV并产生core dump），同时结合公开资料评估，目前来看已公开的RCE并不具备通用性，相关利用链仍在进一步分析验证中。这不等于可以观望——修复这两枚漏洞牵动引擎的内存管理，PHP为此重做了内存中止的时机。部署场景上也有先后：同一解读明确，apache+mod-php环境已可确定容易RCE，漏洞提交者还给出了php-fpm下同样可RCE的演示、只是暂未见他人稳定复现成功。 由此，用mod_php的站点要排在升级队列最前面。360漏洞研究院微博
为什么这次等不起：保密两个月，最后48小时接连破防
这场抢修由OpenAI的"Patch the Planet"计划与PHP维护团队秘密协作了近两个月，原本约定10月22日晚10点统一发布。但10月20日深夜，两个漏洞编号先在网上传开（还混着错误的发布时间和评分），PHP被迫在21日凌晨提前预告、把发布整整前移24小时；随后攻击演示视频被误发流出，含修复的构建镜像也被提前公开，外界已可以对比新旧代码反推漏洞位置。真正压垮"从容升级"预期的是：10月21日下午3点43分，Cloudflare首席技术官Dane Knecht公开确认已经看到早期攻击——而距补丁发布还有六个多小时。新智元
麻烦在于PHP的覆盖面：W3Techs能识别服务端语言的网站中69.3%跑着PHP，底层引擎出事，波及面直接体现在机构行动上。荷兰国家网络安全中心NCSC在10月21日的选择是先关闭官网、等待修复。日本方面，大量服务、游戏和网站在漏洞爆出后集体进入紧急维护状态，日本财务省也暂停了官网部分内容与服务、紧急检查服务器。补丁已经发出，"等一等再看"的选项正式消失了。新智元微博
避坑攻略：升级动作按这五步走
第一步：先搞清楚"升没升成"，别只看版本号。 网站实际由FPM处理时，容器或主机里的命令行版本不能代表一切，必须通过受控的内部诊断确认实际请求中的PHP版本与SAPI，不要在公网保留phpinfo()页面。OpenAI已在22日凌晨放出Codex检查skill，帮网站运营者核对PHP版本、判断是否可能受影响，但它查的是版本，不能替网站完成升级；如果连版本都查不到，也不能据此认定安全。使用发行版回补包（backport）的项目，版本字符串可能仍是旧版本号，要以供应商公告和包修订号为准。知乎新智元
第二步：对号入座选目标版本。 受支持分支的对应关系是：8.2→8.2.35、8.3→8.3.36、8.4→8.4.27、8.5→8.5.12，只升不降、就地打满。PHP 8.1及更早分支已停止官方常规安全维护，官方公告同样提示这些分支可能受到影响，建议升级至受支持版本。官方只为7.4、8.0、8.1准备了最小范围的源码修补，供发行商和长期支持服务制作更新包——这类最小修复对7.4直接关闭了上传进度功能，依赖session.upload_progress的应用要评估功能损失，而不是停在EOL版本上等民间补丁。360漏洞研究院新智元
第三步：别把权宜之计当成修复。 修改php.ini关闭session.upload_progress只是堵住最容易触发的入口，挂WAF规则同理——Cloudflare虽已为其Web应用防火墙的客户部署防护，且发现攻击者在改请求特征绕过规则，但其首席技术官强调这只是临时措施，补丁出来就得安装。两种缓解只应作为"升级窗口期内的过桥手段"，不能写进验收结论。新智元
第四步：容器项目的坑在"重建链路"，不在"拉取"。 如果PHP打进业务镜像，`docker compose pull`只拉取部署配置引用的镜像，不会替你重建业务镜像。要沿FROM基础镜像标签→docker build --pull --no-cache→新业务制品→推送团队仓库→部署机切换镜像逐环节核验：多阶段构建要检查最终运行阶段是否真的换了版本；构建机与部署机分离时，只有本机存在的新标签远端拉不到；restart仍启动原容器，不能代替这次镜像切换。镜像维护者可能尚未发布对应修复变体，不要预设某个-fpm标签已经存在。知乎
第五步：平滑落地和回滚。 先在测试环境验证扩展加载、配置兼容和登录、关键请求、队列等核心链路，再进入原有维护流程；给本次构建使用独有的镜像标签，保留旧制品以便追溯回滚。多副本部署要逐个实例核对，一次exec不能代表全部；队列消费者、定时任务若复用旧镜像，同样在更新范围内。部署后留存证据链：基础镜像digest、新业务镜像标识、各实例实际生效的Web运行时版本。
升级之后：更多"重大漏洞"还在路上
这次的两枚漏洞由AI沿一类早在2004年就存在隐患的内存限额问题审计而得，OpenAI已经预告：PHP只是团队已发现、正在修复的多项重大漏洞之一，未来几个月这类发现预计还会显著增加。同时，新版PHP引擎改变了内存中断的处理时机、设置了软硬两道内存上限，过去对OOM行为做过精细调优的应用，升级后应重点压测内存压力场景，留意退出行为的变化。把PHP版本纳入常态化监控、优先选择跟进补丁快的发行版或镜像源，并关注PHP官方与所用CMS的后续公告，才是这次事件留给开发者的长期功课。新智元
