php2shell漏洞全球暴雷：CVSS 9.2双高危漏洞排查与修复全流程，手把手教你自查PHP服务器是否中招-智慧商城

前言：PHP官方紧急修复php2shell漏洞，两个CVSS 9.2高危漏洞无需登录即可远程代码执行。本文手把手教你用php-fpm版本排查、X-Powered-By响应头检查和Docker容器自查定位风险，并给出关闭session.upload_progress、调整memory_limit及升级修复版本的完整方案。

PHP全球暴雷，我连夜把自己的服务器扒了个底朝天

昨天晚上十一点半，一个做独立开发的老朋友突然给我发微信，就四个字，兄弟救命。

我寻思出啥大事了，一问才知道，他客户的一个网站是用PHP写的，跑在一台三年没动过的服务器上，昨天全网都在传一个叫php2shell的漏洞，他慌得一批，不知道自己中没中招。

我第一反应是先安慰他，PHP嘛，每年不都传几次要完，习惯就好。

结果我打开电脑一查，好家伙，这次不是段子。

10月21号，PHP官方破天荒地发了一个计划外的安全更新，一口气修了两个CVSS评分高达9.2的高危漏洞，编号CVE-2026-109618和CVE-2026-109619，安全圈给这俩漏洞起了个统一的外号，叫php2shell，PHP变shell，直译过来就是，你部署的是个网站，别人拿到手的是个后门。

这俩漏洞最严重的地方在于，不需要任何身份验证，不需要账号，不需要密码，。一个没登录的陌生人发几个精心构造的请求，就能直接在你服务器上执行任意代码。

而且发现它的阵容有点豪华，是Wiz、Calif这两个安全实验室，拉着OpenAI，在一个叫Patch the planet的计划里一起挖出来的。JFrog的研究团队也独立撞上了这个洞，还提前做出了好几个能跑的POC。

然后我看到了一个数字，看到的时候我人都是麻的。

Shodan扫了一下，截至10月20号，全网大概有88万4千台直接暴露在公网上的服务器，还在跑PHP 8.1甚至更老的版本，占上报了版本号的服务器的59%。另外还有74万台压根不告诉你自己是什么版本。

88万台。这还只是敢报版本号的。你敢信？？？

坦率的讲，我看到这个数字的第一反应不是害怕，是好奇。我自己手上不也有几台跑着PHP的服务器么，一台挂着博客的，还有一台帮朋友看着的，到底中没中招？

光看新闻是看不出答案的，我干脆拿自己的服务器开刀，把整个排查流程从头到尾跑了一遍。下面这些，都是我一个晚上亲手踩出来的。

第一刀，我先砍向了最顺手的地方，终端里敲了个php -v。

回车，8.3.2，我心想这不挺新的嘛，虽然按官方标准已经落进中招区间了，但至少不是什么上古版本。

结果我差点被自己蠢到。php -v查的是命令行里那个PHP的版本，而真正在处理你网站请求的，是另一个进程，php-fpm。这俩在你服务器上完全可以是两个不同版本的PHP，就像你家门口刻着张先生，屋里住的其实是李先生。

正确姿势是敲php-fpm -v，看FastCGI进程的真实版本。

我那台博客服务器，fpm跑的是8.3.2，低于8.3.36，中招名单，第一台，命中。

第二刀，我砍向了Docker。

我另一台服务器上跑着个WordPress容器，平时根本想不起来它。进去一看，docker compose exec wordpress php -v，8.1，官方连独立安全补丁都不再给了的版本。

好家伙，第一台命中，第二台也命中，我这排查排查的，把自己排查成重灾区了。

第三刀最有意思，是F12。

你随便打开一个PHP网站的首页，按F12打开开发者工具，看网络请求的Response Headers，如果里面有X-Powered-By这个字段，后面跟着PHP/8.x.x这种字样，那服务器等于把版本号贴脑门上了。

我用这招扫了一圈朋友的几个站，其中有一个，响应头里明晃晃写着PHP/7.4。7.4啊朋友们，官方连针对这个版本的最小修复都只是给了个源码包，让你自己编译去。

对了，Windows服务器的朋友也多留个心眼，2024年那个CVE-2024-4577的CGI漏洞跟这次也算有点亲戚关系，顺手一起查了。

说到这，我得把这次漏洞的原理聊一下，因为不看原理，你根本理解不了官方给的那些临时修复手段为什么长那样。

这次是两个洞，发病机制完全不一样，但病根是同一个，PHP这个25岁的老家伙，身体里有两根从上个时代带出来的血管。

第一个洞，CVE-2026-109619，出在session.upload_progress这个功能上。

这功能是干嘛的呢，就是你在上传大文件的时候，PHP会在服务器上记一个小本本，记录传到百分之多少了，前端好显示个进度条。听着挺贴心对吧。

问题在于，PHP处理上传请求的时候，会把攻击者完全可控的东西，比如文件名，原封不动写进服务器的session临时文件里。然后PHP引擎回头读这个session文件做反序列化的时候，恶意数据就能把内存结构搅乱，构造出一条POP链，最后直接执行任意代码。

而session.upload_progress.enabled这个开关，出厂默认是开的。

所以官方给的临时修复方案是把它设成Off。你想想看这个修复为什么生效，因为它是物理拔引信。开关一关，PHP彻底不再解析和记录任何上传进度，恶意载荷根本没机会写进session文件，整条攻击链从第一步就断了。

第二个洞，CVE-2026-109618，更底层，也更邪门。

PHP处理内存耗尽的时候，用的是一个叫longjmp的老机制，直接跳出去放弃当前请求。这个机制本身没毛病，毛病在于，如果内存恰好在引擎处理到一半、内部数据还没初始化完整的那一刻耗尽，PHP跳出去之后，会留下一堆指向无效内存的半成品状态，后面的清理流程还把它们当成正常数据来用。

这就是经典的释放后重用，UAF。攻击者要做的就是精确计算，用大量请求头、层层嵌套的字段名这些花活，让PHP在看似没超过post_max_size限制的情况下，恰好卡在memory_limit的临界点上爆掉。

那官方为什么建议临时把memory_limit设成-1，也就是不限制内存呢，这个逻辑其实有点反直觉，它是在躲触发路径。内存不设限，无论攻击者的载荷多精确，PHP都到不了那个带着致命缺陷的「内存耗尽中断」的瞬间，进不了那段崩溃逻辑，UAF自然无从触发。

但代价也得说清楚，这么干等于把内存保护拆了，人家用一个简单的DDoS就能把你服务器内存吃满卡死。所以这只是临时绷带，不是手术。

这里有个特别多人都踩过的坑，我必须单独拎出来讲。

改完php.ini之后，必须重启PHP服务。

必须。重启。

因为PHP进程只在启动的时候读一次php.ini，之后配置就焊死在内存里了。你改了文件，不重启，内存里跑的还是那套脆弱的旧配置，改了个寂寞。

FPM环境用systemctl reload php-fpm做平滑重载，别中断线上用户，服务名可能带版本号，比如php8.2-fpm。Apache挂载的mod_php得restart apache2或者httpd。Docker就docker restart你的容器。宝塔用户更简单，软件商店里找到对应PHP版本，设置，重载配置，完事。

改完怎么确认生效呢，最直观的办法是在网站根目录建个test.php，里面写一行phpinfo()，浏览器访问，搜session.upload_progress.enabled，看到Off就稳了。

但是，看完立刻删掉这个文件。phpinfo页面会把服务器的一大堆内部信息全抖出来，这玩意儿留着，等于把自己家户型图贴小区门口。

顺着上面的再聊聊，还有一层很多人会漏掉的排查，WAF。

Cloudflare这类云防火墙已经上了默认的拦截规则，但这里有个要命的细节，如果你的源站真实IP暴露了，攻击者可以绕过CDN直连你服务器，防火墙规则瞬间变成摆设。所以自查一下源站IP有没有泄露，也是这次排查里挺重要的一步。

还有那台7.4的服务器怎么处理。官方已经不给8.1及更早版本出独立补丁了，你的选择只有三个，要么升级到8.2.35、8.3.36、8.4.27、8.5.12这几个修复版本，要么靠Ubuntu、Debian这些发行版的官方安全更新续命，要么找商业LTS供应商买单。没有第四个选项。

排查到后半夜，我把我那两台中招的服务器都升到了修复版本，朋友的7.4也约好了这周末一起迁移。搞完这一切，我坐在椅子上，突然觉得这事挺有味道的。

你知道的，PHP是一个被唱衰了二十年的语言。从2000年代开始，每隔几年就有一波「PHP是最好的语言」的嘲讽，或者「PHP要死了」的预言。结果二十多年过去，全世界仍有超过七成的网站跑在它上面，WordPress、大量的小程序后端、无数公司的祖传系统，全是它。

它像蟑螂，打不死，骂不倒，一直活。

但这次的事情让我意识到一个之前没细想过的东西，活得久，本身就是一种攻击面。

一个语言活了25年，它的身体里就攒了25年的设计决定，里面有些决定在当时完全合理，比如用longjmp处理内存耗尽，比如默认打开上传进度。可是时代变了，攻击者的工具箱变了，这些老血管一根一根，都变成了可以被人顺着摸进心脏的路径。

你今天写的每一行代码，做的每一个「默认开启」的决定，都是未来某一天，别人漏洞报告里的一条注脚。

这不是PHP的问题，这是所有活得够久的东西都要还的账。