先回答标题：能不能「打穿任意」站点？
2026 年 10 月 21 日，PHP 官方发布紧急安全更新，修复两个内核级远程代码执行漏洞（CVE-2026-109618、CVE-2026-109619），安全社区称之为「php2shell」。两者 CVSS v4.0 评分均为 9.2，无需登录、无需用户交互，国家网络安全通报中心和 CNVD 均已发布预警，CNVD 综合评级为「高危」。
「任意站点」这个说法需要拆开看：只要一台 PHP 服务器对外处理 Web 请求，就在攻击面之内——PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeed 均受影响；漏洞出在 PHP 引擎处理异常中断时的内存状态管理，和业务代码写得规不规范无关。但目前公开的完整利用链有前提：mod_php 环境风险偏高，单个未认证请求即可在应用代码运行前触发；FPM 环境的已确认路径则需要特定配置配合，或后续请求恰好落到同一个 worker。所以更准确的描述是：够不到「任意一键打穿」，但离得不远——利用代码已公开流传，安全机构观测到的攻击尝试已累计数百万次，多家机构建议按「已在野利用」对待。
关键结论只有一句：改配置、改代码都挡不住根子上的问题，把 PHP 运行时升到修复版本才是完整方案。
央视也报道了：多国政府网站主动下线避险
这件事的影响力，从媒体的反应速度就能看出来。央视财经援引美国《华尔街日报》等媒体报道了此次漏洞，指出全球约七成使用可识别服务端语言的网站由 PHP 驱动，漏洞可能使攻击者在短时间内控制网站服务器、窃取敏感信息。
各国机构的反应更为直接，多数是主动下线避险，而非确认被攻破：
英国：预算责任办公室网站临时下线，国家网络安全中心同步发布警报，提醒各单位排查服务器是否被植入后门；
芬兰：临时关闭政府面向公众的网络服务；
荷兰：政府门户、港口机构、政党网站以及部分医院网站临时下线；
德国：联邦信息技术中心预防性关停包括部分联邦政府站点在内的多个官网；
日本：多家大型银行和证券公司宣布系统临时维护，铁路公司约 60 个网站暂停服务；
美国：网络安全机构向所有部署 PHP 的机构发出警示，无法立即打补丁的建议直接下线相关服务。
一个政府或金融机构的官网愿意整站下线几天，说明在他们的评估里，「带着漏洞上线」的风险高于「停服几天」的损失。企业官网、商城的负责人不妨对照这个标准掂量一下自己的系统。
一段 Hello World，就能说明问题的严重性
很多负责人的直觉是：「我的官网就几个页面，简单得很，黑客打它干什么？」这次恰好相反——站点越简单，越说明你没做错什么，也越说明你什么都没做错也照样在攻击面里。来看一段全世界入门教程都会写的 PHP 代码：
把这段代码存成 index.php 放到服务器上，一个除了输出 Hello World 之外什么都不做的站点，同样受这两个漏洞影响。原因在于攻击发生的位置：缺陷出在 PHP 引擎处理请求的底层环节，触发时机在任何一行业务代码运行之前。Apache mod_php 环境下，攻击者发送一个特制的 multipart POST 请求，PHP 在解析请求、准备内存的过程中就会触发异常中断路径——此时你的 index.php 还没开始执行，echo 语句根本来不及运行。
换句话说，防火墙拦不住（攻击走的是正常 HTTP 通道）、应用层防护拦不住（攻击发生在应用加载之前）、代码审计更是无从谈起（问题不在你的代码里）。官方明确表示没有任何 php.ini 配置能关闭这两条脆弱路径。这也是为什么一段 Hello World 都保不住自己——这一次要修的不是网站，是网站脚下那层地基。
还有一个背景值得知道：这批问题在 PHP 源码中已存在十余年，此前被认为利用难度太高而不构成现实威胁。今年 8 月，安全研究人员借助 AI 模型审查 PHP 源代码时发现了可用的利用路径，谷歌、OpenAI 等公司的团队随后参与了研究。AI 把「理论上存在」和「实际能利用」之间的距离压缩到了零，也把补丁发布前的细节泄露变成了现实——原定 10 月 22 日的披露计划因细节泄露提前一天。
升级到哪个版本？修复号与维护截止时间对照
官方本轮为四个受支持分支同步发布了修复版，各分支目前的安全维护截止时间如下（依据 php.net 支持版本页）：
| PHP 分支 | 升级到 | 安全维护截止 | 状态 |
|---|---|---|---|
| 8.5 | 8.5.12 | 2029 年 12 月 31 日 | 积极维护中 |
| 8.4 | 8.4.27 | 2028 年 12 月 31 日 | 积极维护中 |
| 8.3 | 8.3.36 | 2027 年 12 月 31 日 | 积极维护中 |
| 8.2 | 8.2.35 | 2026 年 12 月 31 日 | 仅剩约两个月 |
| 8.1 及更早 | 无官方修复版 | 8.1 已于 2025 年底停止维护 | 仅提供源码补丁 |
两点值得注意：其一，PHP 8.2 的安全维护今年 12 月 31 日就到期，这轮修完以后它将不再获得任何安全更新——为这次升级折腾一遍不易，如果项目条件允许，建议跨过 8.2 直接上 8.4 或 8.5，多管几年。其二，仍在跑 PHP 7.4、8.0、8.1 的老系统，官方这次破例提供了源码级的应急补丁（backport），但那只是应急，这三个分支日常已无安全更新，长期方案是迁移到受支持分支。
受影响版本的判定口径很简单：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 及更早的全部版本，都在清单内。WordPress、Drupal、Joomla、Magento、Laravel 等主流建站系统与框架同样受波及——问题出在底层的 PHP 运行时，WordPress 官方明确表示这次不需要核心更新，站长要检查的是实际运行的 PHP 环境。
现在要做的五件事
摸清家底：逐台核对对外服务的 PHP 版本（php -v 或 phpinfo），容器镜像、服务器面板、管理后台里内嵌的 PHP 也要清点——装了新版本不等于业务真的在用新版本。
升级到修复版：按上表对号入座；用发行版软件包的直接更新，包版本号可能不变（补丁被回移），以厂商安全公告为准。
重启 worker：升级后重启 PHP-FPM、Apache 等所有 PHP 进程，旧代码驻留在进程里，不重启等于没升。升级后用 php -v 逐实例核对，不要只看包管理器的返回结果。
临时缓解：实在无法立即升级的，先在 php.ini 或 FPM 池配置中设置 session.upload_progress.enabled=0、收紧 post_max_size，并重启进程——这只能缩小暴露面，不能替代升级；确有需要的可以参考各国机构的做法，先临时下线或做访问隔离。
升级前备份、升级后排查：补丁不会抹掉已有入侵，检查异常进程、可疑文件与日志，必要时轮换数据库与后台凭据。
成本方面：托管在同一服务商下的常规升级，多数属于小时级的操作项；跨大版本迁移（如 7.4 到 8.4）涉及代码兼容性改造，视项目规模以数天到数周计（参考区间，以实际评估为准）。
这次事件留下的两个长期提醒
对多数企业来说，这次漏洞的实际影响是一次紧张的升级；但它暴露出的两个趋势，值得写进运维习惯里。
一个是 AI 正在改写漏洞的发现节奏。过去「存在缺陷」和「缺陷可被利用」之间隔着一道专业门槛，这道门槛给防御方留出了从容修复的时间差；AI 把门槛压低之后，这个时间差在快速缩短。过去觉得「跑了十年都没事」的老系统，未必是安全，可能只是还没人认真打它的主意——这个假设从现在起不再可靠。
另一个是运行时需要进台账。框架和插件有扫描器盯着，PHP 本身往往没人管，而它恰恰是这次出问题的那一层。建议把「每季度核对一次 PHP 版本与维护状态」写进运维日历，和域名续费、证书续期放在同一个清单里。
尊云科技为维护客户提供 PHP 版本巡检与升级迁移支持，如果你的站点还停在已停止维护的版本上，可以先从上面清单的第 1 步开始核对。漏洞的技术细节与运行模式风险差异，可参考我们此前的分析：PHP 惊现两大 CVSS 9.2 未认证远程代码执行漏洞；老版本迁移的取舍可阅读 PHP 8 各版本维护时间表与升级策略，或直接了解我们的 PHP 开发与维护服务。