如果你手上还有对外跑着的 PHP 网站,今晚先做一件事:把 PHP 升到官方刚发的版本。10 月 21 日,PHP 官方紧急发布了 8.5.12、8.4.27、8.3.36 和 8.2.35,修的是两个评分 9.2 的远程代码执行漏洞——不需要登录、不需要后台密码,一个构造过的请求就可能在你自己写的代码跑起来之前把服务器拿下。

先说结论:谁受影响、升到哪个版本
受影响的是所有对外提供 web 请求的 PHP 环境:PHP-FPM、Apache 的 mod_php、php-cgi、FrankenPHP、LiteSpeed 都在内。官方特别点出 mod_php 风险最高,因为攻击可以在应用代码执行前触发,这意味着哪怕你的程序是干净的,也可能被打。修复版本是 8.5.12、8.4.27、8.3.36、8.2.35,各分支都出了;Linux 发行版和 LTS 厂商提前拿到了补丁,所以走系统包更新通常当天就有。
两个漏洞分别是怎么回事
CVE-2026-109618 是内存耗尽(OOM)处理路径上的问题:OOM 发生时 PHP 可能正处在内部请求数据只初始化了一半的状态,随后的请求清理会把这份无效数据当成有效数据来用。CVE-2026-109619 是陈旧全局状态:请求自己的内部状态在它背后的内存被释放之后仍然存活,同一个 worker 处理的下一个请求可能在正常初始化把它重置之前就用到这份旧状态。两个都能被未授权请求触发,所以官方话说得很直:没有完整的缓解办法,升级是唯一安全的选择。
十分钟自查与升级
第一步查版本:命令行执行 php -v,或在 phpinfo 页面看 Version 那一行;顺手确认运行方式(FPM、mod_php 还是 cgi),这一步决定你重启哪个服务。第二步升级:Debian/Ubuntu 先 apt update 再看 php 相关的可升级包;CentOS/RHEL 走发行版源或你的 LTS 厂商源。这里有个坑要避开——官方明确说 rpms.remirepo.net 这个第三方源当天不会更新,依赖它的机器请换成发行版包或自己从源码编译,别在那里等。第三步重启:php-fpm 和 web 服务都要重载,然后重新确认 php -v 已经变成新版本。
实在升不了,先把这两组缓解做上
针对 CVE-2026-109618:把 memory_limit 设为 -1,并且要用应用改不掉的方式设置(比如 FPM pool 的 php_admin_value),避免某个站点的 .user.ini 又把它改回有限值;同时把 post_max_size 压低——不做上传的站设 8M,需要上传的设 32M,upload_max_filesize 保持在 post_max_size 之下;有条件的话在 nginx 或网关层限制请求体大小、字段数、multipart 分段数和嵌套深度,包括没有 Content-Length 的请求。
针对 CVE-2026-109619:把 session.upload_progress.enabled 设为 0,然后重启所有 worker;这个开关必须写在 php.ini、FPM pool 或服务端配置里,不能靠 ini_set 或 .user.ini,因为那些生效太晚。跑 PHP 8.5 的再加一条 fatal_error_backtraces=0。另外把那些会在请求早期输出诊断信息的废弃配置清掉——用 error_reporting 或 @ 把报错藏起来没用。这些都只是降低特定攻击路径的风险,不等于安全。
PHP 7.4、8.0、8.1 的用户怎么办
8.1 及更早的版本 PHP 项目已经不再维护,这次没有官方发布包。官方给的是 7.4、8.0、8.1 三个分支的最小源码 backport,方便自己编译或者没有 LTS 厂商可依靠的人。另外 8.2 会在 2026 年 12 月 31 日结束支持,能一次升到位就别拖到明年。
最后提醒一句:这类漏洞的窗口期通常按小时算,看到公告当天处理是最划算的。具体版本号、缓解参数和完整技术细节,请以 PHP 官方安全公告和 php-src 仓库里的两条安全公告(GHSA-w8hw-w9fx-j79w、GHSA-6wmf-4rv5-p3rp)为准,本文只是把处置顺序讲清楚。
【版权声明】:本站内容若无意侵犯到您的权利,请及时与我们联系将尽快删除相关内容!