PHP2Shell漏洞危机与企业应对指南

大概率不是，绝大多数是预防性停机——先关门、打完补丁再开。看公告里有没有「确认到不正当访问或信息泄露」这句话：写了「没有确认到」的，这种停机不需要改密码。

2026年10月29日

EZ-net@IT研究所｜发布：2026年10月

经营层视角 · 网络安全

PHP2Shell 一周了：你的官网升级了吗

PHP 出了两个高危漏洞：不用密码，攻击者就能远程控制服务器。补丁 10 月 21 日已发，但它装在服务器上，不在 WordPress 里。本文用五分钟讲清三件事：出了什么事、为什么跟你有关、现在该做什么。

一、出了什么事

出事的是 PHP 这门语言本身，不是某家网站。全球约七成网站用它，WordPress、EC-CUBE 这些常见建站系统都跑在它上面。

两个漏洞官方评分 9.2 / 10（Critical），代号 PHP2Shell。说人话：攻击者发一个特制的网页请求，不用登录、不用点任何链接，服务器控制权就交出去了。毛病出在语言内部处理内存的方式上，能追溯到 2012 年——埋了十四年。

69.3%

服务端语言已知的网站中
使用 PHP 的比例

9.2/10

两个漏洞的
官方评分（Critical）

211家

日本当天预防性停机的
服务数量

10 月 21 日官方发了补丁。但关键在下一句：

补丁装在服务器上，不装在 WordPress 里。在 WordPress 后台点「更新」是装不上这个补丁的。这跟网站程序有没有漏洞无关——是地基本身的问题。

攻击尝试每天在发生，安全厂商的蜜罐在补丁发布前 4 天就抓到了利用。但到 10 月 25 日为止，还没有公开确认的大规模成功入侵。这不是「没事」，是「还来得及」。

三个判断，请对号入座。

①你们的官网大概率在射程内。官网、询价表单、会员系统，只要是 WordPress / EC-CUBE / 常见建站系统做的，就是 PHP。

②「修」发生在服务器上，而服务器的责任人常常是空的。共享主机（Xserver、さくら等）由主机商统一升级，等公告就行；但公司自己租的服务器、云上那台「当年谁装的」官网，多半没人管。连 Palo Alto 防火墙的管理界面这次都中招了。

③别人已经用关站投票。日本当天 211 家服务预防性停机：CoDMON、BASE、pixiv、niconico、Xserver、《赛马娘》。欧洲那边，荷兰政务登录 DigiD、法国内政部的地方政务网站、德国联邦 IT 服务商、芬兰、丹麦的政府服务也相继下线。

注意：全是预防，没有一家确认被入侵。他们关站不是因为被打，是因为等不起「确认」。

①问清「谁负责 PHP」

做什么分别向建站公司、主机商、自己的 IT 部门要书面回答：网站跑在什么 PHP 版本上？升到修复版了吗？什么时候升的、升级后重启了吗？

经营判断三个问题里只要有一个答不上来，就说明这件事没有人负责。这比漏洞本身更值得担心。

②把升级排进日程，而不是「研究研究」

做什么对照下表确认自己的分支，升到修复版。

经营判断还在用 8.1 或更老版本的，官方已经不发补丁，必须升级或更换。顺便记一笔账：现在官方还在维护的最低版 8.2，今年 12 月 31 日也停止支持——这笔账早晚要算，这次一起规划到 8.3 以上最省。