PHP 严重漏洞：检查你自己生意或倡议的网站
退伍军人创办的生意、公益组织或教育项目的网站，多半是用 WordPress 做的——也就是跑在 PHP 上。10月21日，这门语言里被发现两个漏洞，攻击者无需任何密码就能接管服务器。我们用最简单的话说明：这与谁有关，该向自己的承包商问什么，以及如果没有承包商该怎么办。
- 发生了什么 — 大多数网站所依赖的语言 PHP 中发现了两个严重漏洞。10月21日发布了修复版本：PHP 8.5.12、8.4.27、8.3.36 和 8.2.35。
- 与谁有关 — 每一个拥有 WordPress、Joomla 或 OpenCart 网站的人——从开着一间工坊的个体经营者，到只有一页网页的公益组织。
- 该做什么 — 给维护你网站或主机的人写一句话：“PHP 是否已升级到2026年10月21日发布的版本？”——并且要拿到书面答复。
许多退伍军人退役后开始自己的生意、接手公益项目或者启动教育倡议——几乎总会在某个时候出现一个网站。它通常是用 WordPress 做的：快、便宜，往往出自熟人或者早已失去联系的自由职业者之手。
2026年10月21日，PHP 团队发布了紧急更新，而欧洲网络事件应急响应团队 CERT-EU 发布了紧急警告。原因是两个危险评分为 9.2 分（满分 10 分）的漏洞，它们让攻击者可以在你的服务器上执行自己的代码。不需要登录，不需要密码，也不需要你做任何事。
下面不用多余的技术语言来讲：发生了什么，为什么连最小的网站也与此有关，以及今天就该写给主机商的那三句话是什么。
究竟发现了什么
漏洞共有两个，评分都是 9.2 分，并且都导致同一个结果：无需授权即可在服务器上执行他人的代码。
CVE-2026-109618 — 内存不足时的崩溃
PHP 中有一项设置 memory_limit：占用内存过多的请求会被强制中断。问题在于它究竟是怎么被中断的。PHP 可能在请求的内部数据只填了一半时就中断——例如正在解析通过上传表单发来的文件。这类请求结束后的清理工作会把未完成的数据当成真实数据，试图释放从来不存在的内存。而那块内存里，可能正放着攻击者通过前面的请求放进去的东西。
CVE-2026-109619 — 上一个请求的残留
第二个漏洞说的是，服务器没有彻底“忘掉”上一位访问者。原本属于某个请求的内部状态，有时会在内存释放之后仍然留存——比如在一次致命错误之后。落到同一个工作进程中的下一个请求，能在常规初始化把它清零之前就用上这些残留。
受到威胁的是任何对外处理网页请求的 PHP 安装：PHP-FPM、Apache 搭配模块 mod_php, php-cgi、FrankenPHP、LiteSpeed。PHP 团队认为最危险的恰恰是 Apache 搭配 mod_php ——这种组合在许多廉价主机上至今仍是标准配置。
演示用的漏洞利用只需一个未授权请求就能成功——甚至在网站自身的代码开始运行之前。也就是说，安全插件、复杂密码、双因素认证在这里都帮不上忙：攻击发生在更低的一层。
哪些版本受到威胁
低于这些版本的一切都是脆弱的：
| 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 8.1 及更早版本 | 已无支持 |
另一类风险是那些内部嵌有 PHP、从外面却看不出来的商业产品和开源产品：管理面板、网络设备、视频监控系统、企业门户。这类软件的清单收录于 荷兰 NCSC 的代码仓库.
为什么“我的网站很小”在这里救不了你
没有人会单独寻找你的网站。当入侵的示例公开之后——而它们已经公开了——自动扫描器会在几个小时内启动，把整个互联网逐个地址扫过去。无论是大公司的网站，还是只有五项服务的小工坊页面，它们都不在乎：唯一重要的是服务器回应的是否为有漏洞的版本。
接下来的情节很固定：服务器上被上传别人的代码，网站开始散发垃圾信息或者别人的广告页面，域名进入黑名单，从它发出的邮件再也到不了客户手里。对小生意来说这是双重的痛：网站往往是唯一的门面，而恢复要花上几周时间和原本没打算花的钱。
另外要提醒随之而来的事。出现这类新闻之后，一些“高手”就会活跃起来，主动给网站主人写信：“你们有漏洞，赶紧把权限给我。”网站和主机的访问权限，只能交给你认识、并且由你付钱做维护的人。
该做什么——分步说明
- 弄清自己的版本。 在主机控制面板里，这是“PHP 版本”或“PHP Selector”一项；在自有服务器上，则是命令
php -v。重要的是查清网站实际运行的版本，而不是命令行里那个版本：两者常常不同。 - 在自己的分支内升级。 从 8.2.29 升到 8.2.35 是同一分支内部的修补：兼容性不变，网站不会因此出问题。不要把它和从 8.2 升到 8.4 混为一谈——后者确实需要测试。
- 如果您用的是 8.1 或更早的版本 ——这些分支已经没有支持。鉴于形势严重，PHP 安全团队也为 7.4、8.0 和 8.1 发布了最小修补，部分主机商还维护着自己的构建。但正确的做法是迁移到受支持的分支，而且最好现在就做计划，而不是等下一次。
- 重启处理程序。 如果不重启
php-fpm或 Apache，工作进程仍会运行旧代码，更新实际上不起作用。 - 检查结果。 最简单的办法是放一个带
phpinfo()的临时页面，检查完立刻删除；或者在重启之后查看面板中的“PHP 版本”一项。
使用虚拟主机的用户大多不必自己动手：大型服务商提前拿到了补丁，会自行更新自己的机器。值得给客服写上一行——“PHP 是否已更新到 2026年10月21日 的版本”——并把答复拿到书面上。
如果现在就升级行不通
有时网站太旧，升级需要准备。那就还有一些临时措施，可以缩小攻击的时间窗口：
- 堵住内存溢出这个入口：
memory_limit=-1，并且要设置成应用无法覆盖，同时检查没有任何池或目录把限制改回去； - 减小
post_max_size——不上传文件的网站设为 8M，需要上传则设为 32M，而upload_max_filesize要保持更低； - 关闭
session.upload_progress.enabled，并重启所有工作进程； - 在 PHP 8.5 上还要额外关闭
fatal_error_backtraces; - 在 Web 服务器或代理这一层限制请求的大小和复杂度。
这些措施中没有任何一项能让环境变得安全。它们只是堵住了已知的路径——真正彻底解决问题的只有升级。
如果连这一点也做不到，CERT-EU 给出的建议简单却不受欢迎：在补丁安装并验证完成之前，把有漏洞的服务从公网上撤下来。
资料来源
- CERT-EU, Security Advisory 2026-018 “Critical Vulnerabilities in PHP”
- php.net 上关于发布更新的公告
- CVE-2026-109618 的技术说明 和 CVE-2026-109619
如果你不知道自己的网站是用什么做的、由谁负责，那本身就足以成为理由，不必等下一条新闻再去弄清楚。检查也可以委托给外部团队——例如 SmartGT，一支负责维护集群数字资源的团队。
本文作者 — SmartGT。原始出处： “PHP 的严重漏洞：升级不能再拖”.