PHP2Shell 正在扫你的独立站，这次的问题不在插件

这两天全球安全机构在集体发警告，原因是一个叫 PHP2Shell 的东西。它不是一个新出的恶意软件，也不是你装的某个插件出了漏洞。问题出在 PHP 本身——也就是你独立站运行的基础环境。

两个漏洞编号：CVE-2026-109618 和 CVE-2026-109619，CVSS 评分都是 9.2。不需要登录后台，不需要知道你的管理员密码，攻击者构造一个特制的 HTTP 请求，就有可能在你的服务器上执行任意代码。

这场危机的来龙去脉很有意思： PHP底层存在一个内存管理漏洞（释放后重用 UAF），在源码里躺了十几年，过去因为利用门槛极高，一直被人类安全专家认为“理论上存在、实际上打不通”。直到最近，安全团队借助AI大模型辅助审查数十万行源码，短短几天内就理清了内存布局并构造出完整的攻击链。AI把“不可能”变成了“现实”，这也意味着漏洞从公布到被黑客利用的时间被空前压缩——留给独立站站长“等两天再升级”的窗口期已经没有了。

为什么独立站这次特别被动

大多数独立站卖家已经养成了一个习惯：安全出问题，先检查 WordPress 插件、主题有没有更新，或者装个安全插件挡一挡。

这次这套逻辑不成立。

PHP2Shell 的攻击面在 PHP 引擎层，请求到达你的 WordPress 或 PrestaShop 应用代码之前，漏洞就已经触发了。你装的 Wordfence、Sucuri，或者任何跑在应用层里面的安全插件，根本没有机会“看到”这个请求。应用层拦不住它。

你的独立站如果跑在 Apache mod_php 上，风险等级被官方标为最高——攻击在应用代码执行之前就完成了。PHP-FPM 环境同样在受影响范围内，包括 Docker 里的 PHP-FPM 镜像。

你现在只需要做一件事：看版本，然后升级

第一步，确认你的 PHP 版本。

在服务器上跑一下：

text

php -v

如果输出在以下范围内，就处于风险中：

• PHP ≤ 8.5.11
• PHP ≤ 8.4.26
• PHP ≤ 8.3.35
• PHP ≤ 8.2.34

第二步，升级到修复版本，然后重启 PHP 服务。

当前分支	需要升级到
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

升级完不等于结束。必须重启 PHP 进程（PHP-FPM 或 Apache），因为旧 worker 进程里的残留状态本身就是攻击入口之一。

PHP 8.1 及更早版本已经不再接收官方安全更新，没有可以直接打的官方补丁。如果你还在这些版本上跑独立站，这次是一个明确的信号：该迁移了。

别用“临时缓解”骗自己

官方公告里列了一些临时配置项，但措辞非常明确：更新是唯一完整的修复方式，缓解措施只能降低特定路径的暴露面，不能保证系统安全。

你的独立站如果过去几天一直暴露在公网上，并且 PHP 版本不在修复范围内，升级之后值得做一件事：检查有没有异常进程、异常文件，以及数据库和 API 凭据是否泄露。漏洞一旦被利用，攻击者拿到的权限可以读取你的配置文件、数据库密码和 API key。

把版本查清楚，剩下的交给服务器

你不需要看懂 longjmp 或者 use-after-free 的细节。你需要知道的是：你的独立站底层跑的是 PHP，而 PHP 本身刚刚被证实可以被未登录的人打穿。 修复方式不复杂，但前提是有人真的去看版本、真的去重启服务、真的确认每一个跑网站的 worker 都换到了新版本上。

这件事，需要的话，独立站扫地僧可以协助。