PHP2SHELL 自查手册来了｜3 条命令当场见分晓

原创

Flag
Flag

网络安全实验室

2026年10月23日 14:02
辽宁

去阅读

站点被黑还蒙在鼓里？PHP2SHELL 自查手册来了｜3 条命令当场见分晓

别再蒙在鼓里，3 条命令揪出后门。

你的站点功能一切正常，首页秒开，后台也能登，报表照常出。可就在你觉得天下太平的时候，攻击者可能已经通过一次不起眼的 HTTP 请求，在服务器内存里埋了后门。

这不是吓唬人。2026 年 10 月，PHP 官方披露了CVE-2026-109618和CVE-2026-109619两个高危漏洞，安全圈统一叫PHP2SHELL。它有两个让人头疼的地方：一是攻击者不需要任何账号密码，构造一个特殊的 multipart 请求就能远程执行代码、或者读走内存里的敏感信息；二是漏洞触发发生在网站代码执行之前，你部署的 WAF、防火墙、业务层的各种防护，基本都拦不住。

更麻烦的是，这类漏洞走的是内存级利用，中招后不像传统木马那样留一个明显的后门文件，服务器表面看不出异常。它最坑的就是：你中招了，但你自己不知道。

与其等被通报、被勒索、或者数据被拖走了连夜抢修，不如现在花 5 分钟，按下面的 3 条命令给自己查一遍。

先说这漏洞到底怎么回事

一句话讲清：PHP2SHELL 不是业务代码漏洞，是PHP 引擎自身的一对\"释放后使用\"（Use-After-Free）漏洞，出问题的是 PHP 处理完请求后\"收尾清理\"那个环节。

正常来说，PHP 的每个工作进程处理完一个请求，会把这次的临时状态清空、把内存还给系统，干净地迎接下一个请求。但这两个 CVE 就坏在清理没做干净：某个内部指针在内存释放后没被重置，还指着那块已经不属于它的空间。

攻击者就利用这一点，让同一个工作进程在处理连续两个请求时，一个当\"生产者\"、一个当\"消费者\"：第一个请求把敏感数据或攻击载荷写进那块\"幽灵内存\"，第二个请求再读出来，最终实现远程代码执行，或者内存敏感信息泄露。全程不需要账号密码，构造一个 multipart 请求就能触发。

这里有两个要点，直接决定你的防御思路：

一是触发点在业务代码之前。它借助 session.upload\_progress 机制，在 PHP 跑任何网站代码之前就引爆了。所以你写的过滤器、参数校验、业务层 WAF，都拦不住。

二是影响面太大。官方通告说，从 PHP 5.4 到最新版几乎全线中招，严重度 9.2；其中以 Apache mod\_php 方式运行的站点风险最高，默认配置就能被利用。

搞懂了这些，你就明白为什么针对这个漏洞的自查，重点不是翻业务代码，而是盯住引擎版本、运行模式、临时缓解配置和利用痕迹这四件事。

第一条命令：先看你有没有被波及

第一步别急着翻文件，先确认你的服务器在不在风险范围里。一条命令就够：

php -v

它会打印当前 PHP 解释器的版本号。对照官方修复版本，只要你的版本低于下面这行对应的版本，就还在受影响区间：

PHP 8.2 → 需 ≥8.2.35

PHP 8.3 → 需 ≥8.3.36

PHP 8.4 → 需 ≥8.4.27

PHP 8.5 → 需 ≥8.5.12

PHP 5.4 ~ 8.1 → 均受影响，尽快升级或启用临时缓解

这里有两个坑得提醒你。

第一，命令行版本不等于线上版本。很多服务器装了多套 PHP，php -v 显示的是命令行那套，网站实际跑的可能是另一套。更稳的办法，是在网站根目录临时放一个 phpinfo() 探针（用完即删），看 \"PHP Version\" 和 \"Server API\" 两栏，那才是线上真实版本。

第二，运行模式决定风险等级。这个漏洞对 Apache mod\_php 威胁最大，默认配置即可被利用。确认是不是 mod\_php 可以这样：

httpd -M 2>/dev/null | grep -i php

输出里有 php\_module 或 libphp，说明 Apache 正以 mod\_php 方式加载 PHP。这种情况属于最高危的一类，直接跳到下面两条命令做完整排查，并尽快安排升级。看到的是 php-fpm、php-cgi 这类字样，风险相对低一些，但也得补，别掉以轻心。

到这儿你知道了自己\"有没有暴露\"。但还不够，第二条命令看看你有没有先止血。

第二条命令：看你有没有先止血

如果一时半会没法升级 PHP 版本，官方给的临时缓解方案，就是关掉 session.upload\_progress 这个机制，它正是 CVE-2026-109618 触发链条的入口。第二条命令就是确认你到底关没关：

php -r \"var\_dump(ini\_get('session.upload\_progress.enabled'));\"

看输出：

输出 bool(false) 或 string(0) \"\" → 已经关闭，做了临时缓解，暴露面被大幅压缩；

输出 string(1) \"1\" → 还开着，利用链随时可能被触发，高风险，尽快处理。

缓解配置是在 php.ini（或 PHP-FPM 的 pool 配置、Web 服务器配置）里加这一行，改完记得重启所有 PHP 进程才生效：

session.upload\_progress.enabled = 0

这里有两件事必须说透：

第一，别只查命令行。和版本一样，php -r 默认读的是命令行那套 php.ini，线上网站可能跑的是独立配置。改完配置后，最可靠的方式还是用 phpinfo() 探针，在页面里搜 upload\_progress，确认线上那个值真的变成了 Disabled。

第二，这是\"止血\"，不是\"治愈\"。关掉 session.upload\_progress 只能大幅降低被利用概率，堵不住漏洞本身（CVE-2026-109619 那条利用链并不完全依赖它）。它只是为你争取升级时间的临时手段，终极方案还是升级到修复版本，别把\"关了就行\"当成长久之计。

到这一步，你已经查清了\"有没有暴露\"和\"有没有止血\"。还剩一个最揪心的问题：如果已经被打了，怎么发现？第三条命令就是干这个的。

第三条命令：翻日志，找被攻击的痕迹

版本没补、upload\_progress 没关，前两条命令都在回答\"我会不会被影响\"。但真正让人心里发毛的是：我是不是已经被打过了？第三条命令，就是回头翻日志找痕迹。

PHP2SHELL 的利用请求有个鲜明特征：攻击者要构造包含大量头部、嵌套字段名或空文件控件的 multipart 请求，去触发内存分配失败、制造 UAF 状态。这类请求在日志里往往表现为异常密集的 multipart POST，和正常业务流量明显不一样。可以这样筛（以 nginx 为例，Apache 把日志路径换成 access\_log 对应位置）：

1) 先看有没有大量 multipart 请求堆积

grep -c 'multipart/form-data' /var/log/nginx/access.log

2) 找出 POST 请求最集中的来源 IP 与路径，看是否有攻击性

grep -E 'POST' /var/log/nginx/access.log | awk '{print $1, $7}' | sort | uniq -c | sort -rn | head -20

判定思路：如果某个来源 IP 在极短时间内向同一路径发起大量 POST（尤其是 body 异常大、带空文件控件特征的请求），同时你的 PHP 版本又在受影响区间，就要高度警惕，这很可能就是正在进行的利用探测或攻击。

但得提醒一句，这个漏洞走内存级利用，攻击者未必会立刻在磁盘上留下明显的 webshell 文件。所以光看请求特征还不够，最好再顺手查一下近期新增或被动过手脚的可疑文件：

find /var/www -mtime -7 \( -name \"\.php\" -o -name \"\.jsp\" \) -type f 2>/dev/null

重点看那些名字毫无规律、体积异常、或者修改时间恰好和攻击时段吻合的 PHP 文件，它们可能是利用成功后落地的后门。日志特征和可疑文件同时命中，基本可以判定中招，直接跳到最后的应急三步。

最后，真中招了怎么办

把 3 条命令串成一套完整的自查逻辑，按这个顺序走一遍，心里就有底了：

命令一

（php -v + 确认运行模式）回答\"我暴露了吗\"。版本在受影响区间、又是 mod\_php，直接进入高度警惕；

命令二

（查 session.upload\_progress）回答\"我止血了吗\"。enabled=1 就赶紧关掉，争取升级时间；

命令三

（翻日志 + 查落地文件）回答\"我被打过吗\"。multipart 攻击特征和可疑后门文件同时命中，基本判定中招。

真中招了也别慌，按应急三步处理：

第一步，隔离。第一时间把受影响服务器从生产环境断开，切断横向扩散，别让攻击者顺着这台机器打进内网其他系统。

第二步，取证。清理之前，先做内存和磁盘快照，完整保留日志和可疑文件，这些是后续溯源、追责、甚至报案的关键证据。切记先取证、后处置，顺序不能反。

第三步，修复与清理。升级到修复版本（8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 及以上），关闭 session.upload\_progress，再彻底排查并清除落地后门，最后重启所有 PHP 进程确认生效。

最后再说一句。PHP2SHELL 是 AI 挖出来的，这本身就说明攻防节奏变了：AI 一天能发现人类几年漏掉的漏洞，攻击者的自动化工具也会越来越快。对这类内存级、触发在业务代码之前的漏洞，任何基于业务层的过滤都靠不住，唯一靠谱的就是及时升级 + 持续自查。把这三条命令存下来，纳入日常巡检清单，别等被通报了才想起来。