一个请求就能拿下服务器：PHP 爆出 9.2 分严重漏洞，攻击已在路上

HackerNews
HackerNews

安全威胁纵横

2026年10月22日 10:49
湖北

去阅读

这次出事的不是你的网站代码，是PHP本身。攻击者不需要账号，一个请求就能在服务器上跑代码。

推测e

本文由Aipy编译整理，封面图由Aipy生成

1

先说结论：去更新PHP

PHP官方发布了紧急更新，修的是PHP语言本身的两个严重漏洞。攻击者不需要任何账号，就能在你的Web服务器上执行代码。

修复版本是这四个：PHP 8.5.12、PHP 8.4.27、PHP 8.3.36、PHP 8.2.35。

PHP团队说得很直白：只有更新，才能完全保护服务器。

2

这两个漏洞为什么麻烦

两个漏洞被统称为PHP2Shell。

它们不在你的网站代码里，而在PHP运行时里。这意味着——哪怕你的网站代码写得干干净净，服务器一样会中招。

风险最高的是使用Apache mod\_php的服务器。可用的利用代码会在任何应用代码运行之前就触发攻击。

两个漏洞在CVSS v4.0评分中都是9.2分，编号分别是CVE-2026-109618和CVE-2026-109619。

PHP在10月21日14:00 UTC的预定发布时间前后公布了它们。而在此之前一天，细节就已经泄露了——原计划是10月22日披露。

漏洞由Wiz、Calif和OpenAI的研究人员发现并报告，影响范围可追溯到PHP 5.4的几乎所有版本。

3

谁受影响

按PHP安全公告的说法，所有处理Web请求的PHP安装都面临风险，包括：PHP-FPM、Apache mod\_php、php-cgi、FrankenPHP、LiteSpeed。

因为漏洞在引擎里、不在网站代码里，所以哪怕你只是在有漏洞的PHP版本上跑一个简单的\"Hello World\"页面，也可能被攻击。

公告特别点名mod\_php风险最高，并演示了一个利用过程：单个未经身份验证的请求，就能在任何应用代码运行之前触发攻击。

PHP-FPM的表现不太一样——它在请求早期设置失败时会关闭worker。

具体到两个漏洞：其中一个，PHP自己的分析认为FPM也易受影响，但表示尚未展示完整的FPM利用；另一个已被证明可以在mod\_php和PHP-FPM上达到代码执行，不过FPM路径依赖运行中应用内的某个操作。

还有一点容易被忽略：攻击者不需要先拿到代码执行权限，就能读取PHP worker进程的内存。这块内存里可能躺着别的请求的密码、身份验证令牌、API密钥和证书。

研究人员在并非自己控制的应用程序上演示了读取实时worker内存的能力——也就是说，这个风险和跑在PHP之上的具体应用无关。

4

该装什么

更新处理Web请求的PHP运行时，然后重启Apache、PHP-FPM，以及任何长期运行的PHP worker。

这里有个常见误区：更新WordPress或Laravel这类应用，并不会更新它们底下的PHP运行时。PHP运行时来自服务器软件包、主机或容器镜像。

版本对照表：
PHP 8.5分支：低于8.5.12的易受影响，修复版本8.5.12
PHP 8.4分支：低于8.4.27的易受影响，修复版本8.4.27
PHP 8.3分支：低于8.3.36的易受影响，修复版本8.3.36
PHP 8.2分支：低于8.2.35的易受影响，修复版本8.2.35

PHP 8.1及更早版本已经不再从PHP项目获得更新。PHP 8.2将于2026年12月31日生命周期终止。

对于较旧的分支，PHP安全团队已经发布了PHP 7.4、8.0和8.1的源码回移补丁，方便从源码构建或等待厂商的用户。

Linux发行版和长期支持厂商提前拿到了补丁，所以发行版软件包可能在看起来陈旧的版本号下就已经带着修复。就像Debian建议的那样：去查软件包变更日志里的CVE编号，别只看版本号。

5

如果暂时没法更新

只有更新才是完整的修复。下面的措施能减少特定攻击路径的暴露，但并不能让服务器变安全。

针对CVE-2026-109618：

1. 把memory\_limit设为-1，让应用无法覆盖它
2. 保持post\_max\_size较低
3. 在Web服务器或代理层强制执行请求大小限制
4. 不要用RLIMIT\_AS或RLIMIT\_DATA作为替代——PHP警告说它们可能触发同一条易受攻击的路径

针对CVE-2026-109619：

1. 设置session.upload\_progress.enabled=0，并重启每一个worker
2. 在PHP 8.5上，还应设置fatal\_error\_backtraces=0

关闭会话上传进度能阻断已确认的会话路径，但阻断不了其他变体。除了更新，没有任何配置更改能完全缓解这个漏洞。

这个设置是在补丁发布前流传的变通方法，而这次发布确认了：它从来都不是完整的修复。

会话上传进度默认是开启的，并且可能在PHP完成请求设置之前就触及会话处理——这就是它卷入CVE-2026-109619一条已确认攻击路径的原因，也是关闭它对CVE-2026-109618毫无作用的原因。

PHP核心开发者Gina Peter Banyard在发布前回复一位认为该设置可能足够的用户时写道：\"我唯一能说的是，唯一的缓解措施就是给PHP打补丁/升级。遗憾的是我知道得太多了。\"

更新之后，请检查内存设置。这次修复引入了一个新的硬性内存限制，达到该限制会终止进程，并阻止关闭处理程序运行。所以要根据应用需求，检查memory\_limit和post\_max\_size。

6

已经打了补丁，但怀疑之前被入侵过？

研究人员建议留意这几个迹象：

1. 异常的多部分请求，之后跟着内存限制错误，或反复出现的HTTP 500响应
2. 异常巨大的PHPSESSID响应cookie
3. PHP worker出现无法解释的重启

7

现在正在被攻击吗

补丁发布之前，Cloudflare就表示已经看到利用这些漏洞的早期尝试。

Cloudflare CTO Dane Knecht说：\"我们看到早期攻击正在出现，并随着新向量的出现更新缓解措施。\"他还说，Cloudflare部署的防火墙规则只是权宜之计，并敦促管理员打补丁。

目前还没有来源确认成功入侵。

复现了CVE-2026-109618的watchTowr报告称，截至10月21日11:26 UTC未发现在野利用。当时两个漏洞都不在CISA的已知被利用漏洞目录中。

一些组织是出于预防、而非应对任何入侵而下线服务的：

BambooHR在美国、加拿大和爱尔兰下线了服务，警告薪资发放将中断，并表示尚无恢复时间。

在荷兰，据广播公司NOS报道，MijnOverheid、DigiD、议会下院网站、国家网络安全中心和多个教育系统下线。该中心表示尚未看到该漏洞被滥用，但敦促所有人打补丁。

8

事情是怎么曝光的

一次泄露，让发布提前了。

据The Hacker News报道，10月20日，Hacker News上出现一篇帖子，称两个PHP远程代码执行漏洞（附有两个CVE编号）将于10月22日披露——依据仅仅是一条可信的线报。

PHP当晚发布了预先通知，并把发布提前到10月21日。

顺带澄清一点：泄露消息里说的CVSS 10.0评分并不是PHP的评定。PHP给两个漏洞都评的是9.2。

这些漏洞由Wiz Research、Calif和OpenAI的Codex Security团队发现，并与PHP安全团队及Google的Gemini团队合作修复。底层代码已经在PHP里存在了十多年。

研究人员表示，AI模型帮助把这些长期存在的漏洞转化成了可用的利用代码——一名研究员在大约一周内，完成了他们所说的原本需要团队数月才能完成的工作。

Calif把该漏洞的谱系追溯到了2004年的PHP研究。它表示，了解目标的历史仍然很重要，当前的模型无法可靠地自行从那些晦涩的、二十年前的原始原语出发。

9

更新：watchTowr报告利用尝试，仍无确认入侵

当天早些时候报告\"未发现任何情况\"的watchTowr，在10月21日14:19 UTC的新公告中表示，正在观察到针对CVE-2026-109618和CVE-2026-109619的\"活跃利用尝试\"。

Cloudflare表示看到了针对其客户的攻击流量，并观察到攻击者更改载荷以绕过其防火墙规则——该规则已在补丁前的03:02 UTC默认开启。

截至这次更新，尚无来源报告特定服务器被确认入侵。

PHP基金会表示，协调披露在发布前就已经瓦解：

10月20日约20:00 UTC，研究公司Calif误发了其可用概念验证的视频；10月21日07:41 UTC，也就是修复发布前约六小时，厂商Chainguard发布了包含补丁的构建镜像，使任何人都能在其他用户等待更新时研究这个修复。

10

更新：PHP基金会称2024年审计发现了首个迹象

在同一篇帖子里，PHP基金会表示：一名核心开发者在PHP 2024年外部审计期间，首次发现了CVE-2026-109618背后内存耗尽漏洞的迹象。但当时只推测出可用的攻击，并未找到具体的代码执行路径。

修复为什么拖了这么久？因为相互竞争的修复方案，各自都有风险：破坏兼容性、开启拒绝服务路径、强制第三方扩展更改。

一个小团队难以达成一致，修复工作因此停滞了数月。基金会称这一延迟是其决策流程和资源的\"结构性失败\"。

转机出现在2026年：Calif、OpenAI和Wiz使用AI工具提交的报告确立了可用的利用代码，让这个漏洞的完整影响变得清晰，并把修复推到了队列首位。

基金会表示，此后已经改变了安全决策方式，并增加了人员和工具，以便更早发现类似问题。

11

一句话行动清单

1. 查版本：对照上面的表，看你的PHP是不是低于修复版本
2. 打补丁：更新PHP运行时，不是更新WordPress或Laravel
3. 重启：Apache、PHP-FPM、所有长期运行的PHP worker
4. 查日志：看软件包变更日志里的CVE编号，别只看版本号
5. 复查内存设置：memory\_limit和post\_max\_size要按应用需求重新确认

写在最后：这次最值得记住的不是9.2分，而是一个常识——应用更新了，不等于运行时更新了。转发给还在用老版本PHP的朋友，比事后排查省事得多。

转载请注明出处@安全威胁纵横

本文由Aipy编译整理，封面图由Aipy生成，消息来源：https://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html