10月21日夜里，无数PHP开发和运维的群聊炸了。不是因为某个框架又发breaking change，而是PHP官方直接预告并上线了两个Critical级远程代码执行漏洞的安全修复：CVE-2026-109618和CVE-2026-109619，社区把它们合称为"PHP2Shell"。10月21日起，欧洲、日本不少政府网站先后暂停服务。FGO等多款游戏因PHP安全漏洞宣布紧急维护，pixiv、Cygames全家桶等一批日本手游跟进。宝塔面板的Nginx防火墙支持PHP漏洞一键防护，Cloudflare也官宣部署了针对性防御。。哔哩哔哩知乎哔哩哔哩
对靠PHP吃饭的人来说，这两天信息密度过高、噪音更大。我翻了PHP官方公告、知乎、B站、36氪和一堆公众号的分析，把"事实"“误读”"你现在该做的动作"拆开讲清楚——尤其是最后那三类补了补丁依然漏防的情况，社区里已经有站长实打实踩中了。
先把时间线钉死
10月20日：PHP官方发布预告"Upcoming Critical PHP Security Release"，罕见地提前一天打预防针。
10月21日：正式安全公告与修复版同步发布，补丁版本为 8.5.12、8.4.27、8.3.36、8.2.35，8.1及更早版本没有官方更新。欧盟计算机应急响应团队给这次漏洞的CVSS评分为9.2，表明存在未经身份验证的远程代码执行风险。哔哩哔哩知乎
10月21—22日：央视新闻报道、多家媒体跟进。荷兰国家网络安全中心（NCSC）直接宣布把自己的官网（ncsc.nl）暂时下线。披露后黑客攻击尝试明显激增。微信公众号
10月23日：PHP官方补充公告"Informational advisory: Session upload progress"——这才是多数人真正漏掉的那一环，下面单独讲。
一句话定性：这是PHP近年罕见的高危RCE+全球大修补窗口，但"预防性下线"不等于"已入侵"，恐慌要校准。
“全球70%网站遭殃”，是最容易被读错的一句
Wiz Research的原话是"AI uncovers critical RCE vulnerabilities affecting 70% of the Internet"。配合W3Techs的统计——约七成网站的服务端脚本在用PHP——很多人直接理解成"七成网站要完"。哔哩哔哩
错。70%说的是暴露面：你的技术栈里有没有PHP这个组件；不是失陷率：装了PHP就一定会被打穿。实际风险取决于三件事：PHP版本是否在受影响区间、有没有跑到未修复的旧线、以及你的应用和配置是否触达漏洞路径。知乎上专门做安全的分析也指出，这两个漏洞并没有简单的直接利用方式，利用门槛不低。知乎
所以正确姿势是：把"70%"当动员令，不当判决书。该修必修，但不用跟着短视频恐慌性拔网线。
第一个坑：升级完成了，漏洞可能还在
B站有个视频标题特别典型——《辛苦一天PHP终于升级完，结果漏洞可能还在？》。评论区一堆站长实测中招，原因简单粗暴：补丁生效需要重启每一个PHP worker。哔哩哔哩
PHP-FPM是常驻进程，`php -v`看到版本号变了，不代表内存里跑的还是那个旧二进制。只`systemctl reload` FPM主进程不够，必须完整重启（`systemctl restart php-fpm`或对应服务名），Apache mod_php同理要重启服务。有LiveOverflow的复现视频演示过"补丁后未重启"状态下漏洞依然可达——这不是段子，是部署习惯问题。
自查很简单：重启后直接请求你的站点，再用`php-fpm`进程列表确认worker的启动时间晚于升级时间。托管主机/云虚拟主机的，别只看面板版本号，找客服书面确认"已更新且已重启"。
第二个坑：更新WordPress，不等于更新PHP
事件爆发后大量WordPress站长第一反应是把主题插件更新到最新——方向完全错误。这次要命的是PHP引擎本身，底下跑的还是带洞的8.3.x/8.4.x就照样有暴露面。研究人员已经在部分WordPress、Drupal、Joomla部署上，复现了未登录的远程代码执行。宝塔面板这次动作快，正是因为它的用户群基本是"面板里点一下PHP版本切换+重启"的中小站长。微信公众号
宝塔用户的正确顺序：面板→PHP版本切换到修复版（8.2.35/8.3.36/8.4.27/8.5.12对应你的大版本）→安装→在"网站"设置里确认站点实际调用的是新版本→重启。Nginx防火墙的"一键防护"可以作为临时缓冲层——它是虚拟补丁思路，能挡已知利用特征，但不能替代升级PHP本身。
第三个坑：8.1及更老版本，官方不给你修
公告里最残酷的一句话：8.1及更早版本没有官方修复，想打补丁都没得打。要么找你的Linux发行版/云厂商拿带商业支持的backport补丁，要么直接升大版本。微信公众号
现实是，国内大量老政务、老企业站还挂着5.x/7.x——"php2shell潜伏二十多年"这种说法（LowLevel等视频在传）虽然后续细节还在被核，但老版本没有补丁、没有安全线、又暴露在公网，是这次事件里最沉默的受害者。如果你的存量站还在8.1以下，这次就是最硬的升级理由：8.2.35到8.5.12都有官方修复线，先把PHP升上去，业务代码兼容性问题在测试环境解决，别再拿"跑得好好的不敢动"当借口。
10月23日的补充公告，才是最容易漏的细节
大部分人10月21日升完版本就躺平了，但PHP官方10月23日又发了一条信息性公告：在一种特殊配置组合下——应用运行时用`ini_set()`把`session.serialize_handler`改成`php`——存在另一条"不太可能被利用"的远程执行风险路径，涉及`session.upload_progress`特性，官方建议在下一个常规修复版发布前设置`session.upload_progress.enabled=0`。哔哩哔哩
官方给的建议值得逐字看：
这项设置必须写在php.ini、FPM pool配置或服务器配置这类"请求解析前就生效"的位置；
`ini_set()`和FPM的`.user.ini`里写不算——因为要在请求解析前生效；
改完还是要重启worker；
如果你的应用从不在运行时改serialize handler，可以保持开启，不必恐慌性关闭。
这个坑毒就毒在：配置写了但写错位置（`.user.ini`），你以为防了其实没防。用`phpinfo()`（别对公网暴露）或`php -i`确认`session.upload_progress.enabled`的Local/Master值确实是Off才算完。
该继续盯着什么信号
PHP官方下一条补充公告：10月23日这种"二次打补丁前的临时缓解"说明官方还在跟踪利用面，官网news页要设关注。
攻击面数据：披露后攻击尝试激增，但"百万级攻击"之类流传数字口径不一，以Cloudflare、watchTowr这类一线遥测/安全厂商报告为准。
8.1以下存量站的兜底方案：发行版和云厂商的backport进度，决定老站是"暂时没洞"还是"一直有洞"。
AI挖洞的常态化：这次是OpenAI"Patch the Planet"计划下AI智能体参与发现披露的。叠加此前Node.js漏洞同样出自AI红队，安全圈讨论的共识是这类事件不会停。对PHP开发者的实际影响：以后"升级依赖"不再是可选项，版本管理和补丁响应速度会变成岗位硬要求，做外包、做运维的，把`php -v`和重启确认变成肌肉记忆。哔哩哔哩
最后说句圈内的：全球七成网站靠这门"被调侃了二十年的世界最好语言"撑着，出事的时候没人能绕开它。补丁48小时里，PHP基金会"全职维护资源有限"的现状梗又被翻出来群嘲——你可以继续玩PHP的梗，但梗归梗，今天先把worker重启一遍。
