PHP高危漏洞已遭实际利用！服务器用户请尽快检查
这次的情况已经不是所谓的可能存在风险, 而是实际的攻击行为已经全面爆发。在10月21日这一天, PHP官方正式发布了紧急版本的更新内容, 专门用来修复那两个允许未授权状态下远程执行代码的严重级别漏洞, 这种组合漏洞被统称为 PHP2Shell。
当这个补丁包刚刚放出仅仅十几分钟不到, 相关的蜜罐设备就已经记录到了针对这些漏洞进行利用的大量流量数据。目前来看, 这次出现的有关PHP高危漏洞的问题已经被黑客在实战中直接利用了, 所以使用服务器服务的用户群体请尽快去检查自己当前所运行的软件版本情况。
PHP的这个漏洞是在引擎这一层上面出现的, 服务器的安全方面是没有半点侥幸可以占的, 你不要等到自己的网站确实出了麻烦事情之后再回过头去进行修补操作。
两个编号，一个根源
CVE-2026-109618, 也就是因为内存耗尽而导致内部状态被损坏的问题, 还有CVE-2026-109619, 这个漏洞涉及到请求级别的残留状态问题, 这两个PHP漏洞的发生位置, 实际上都是在引擎本身那里。
也就是说, 问题并不是出在 WordPress、ThinkPHP 或者某一个插件上面, 就算应用层写得再严密, 也抵挡不住这个影响, 它会影响到 Apache mod_php、PHP-FPM、php-cgi、LiteSpeed、FrankenPHP 这些常见的运行方式。
受影响范围从 PHP 5.4 一直到 8.5.11。官方给出的修复版本是 8.5.12, 还有 8.4.27, 另外有 8.3.36, 以及 8.2.35。对于从 5.4 到 8.1 这些已经停止维护的版本, 没有正式的更新可以拿到, 因此只能升级到受支持分支才行。
马上要做的四步
- 去查一下那个真实的版本详情。命令行里运行 php -v 这个命令得到的结果, 仅仅是控制台的那个版本而已, 实际上网站正在运行的是 PHP-FPM 或者是作为服务器模块加载的那些版本, 这两者之间很有可能是完全不同的情况。你可以临时性地放置一个用来显示 phpinfo 信息的页面, 通过查看其中的 Server API 字段来获取信息, 或者也可以逐个去核对控制面板里每个站点具体绑定的 PHP 版本数字是什么, 在完成这些查看操作确认信息之后, 必须立刻把这些临时性的页面或者记录给删除掉。
- 升级并重启。在将版本升到对应分支的最新之后, 需要重新启动 PHP-FPM 以及 Web 服务；如果是 Docker 环境的话, 必须重新构建镜像, 如果只是更换了文件而没有进行重启操作的话, 那就等于完全没有实现升级的效果。
- 进行一下复核的操作, 目的是为了再一次确认网站站点实际加载出来的那个版本是什么, 这样就可以避免那种已经安装新版了, 可是网站站点却依然指着旧版不松手的情况的发生。
- 备份。在升级之前需要做一次备份操作, 然后在升级完成之后也需要再进行一次备份操作, 存放这些备份文件的位置绝对不可以放在Web根目录里面。
暂时不能升级怎么办
在公开分析当中提供的临时性的缓解措施, 是关闭 php.ini 里面的 session.upload_progress.enabled, 这样做可以掐断一条已知的利用链；Web应用防火墙也只能拦截已知的特征表现。
这两个方法都是起到止血的作用, 并不能替代补丁的安装。如果业务方面允许的话, 先停止运行 PHP 或者临时把站点下线, 会显得更加彻底一些。
已经中招的迹象
我们要重点关注 10 月 17 日之后的记录, 看看 Web 目录里是不是新出现了 PHP 文件, 比如一句话木马或者加密壳。还要查看有没有异常的子进程在运行, 站点是不是主动去连接陌生的 IP 地址。
另外, 日志里如果出现大片的畸形 multipart 数据, 或者是超长的 Cookie, 也属于异常情况。在发现这些异常以后, 要先进行隔离操作, 并且保留好相关的证据。紧接着, 我们再清理掉那些后门程序。最后, 还需要修改数据库的密码以及后台登录的密码。
排查思路可以参考网站被挂马的原因排查，环境升级可以看宝塔面板漏洞升级。
常见问题
怎么判断我的服务器是否受影响？
你可以查看网站在实际上运行时所使用的 PHP 版本, 只要该版本低于 8.5.12、8.4.27、8.3.36、8.2.35, 那么它都属于受影响的范围。对于从 5.4 到 8.1 的版本, 由于没有得到官方的补丁支持, 因此必须进行分支升级。
只装 WAF 不升级行不行？
这个情况是不行的。因为漏洞存在于引擎这一层面, 然后WAF这边只能是去匹配那些已知的攻击特征, 一旦那些绕过的手法出现, 它马上就就没有用了, 所以最后才是那个补丁才能够成为那个根本性的解决办法。
升级后还要做什么？
把 PHP 的进程和 Web 服务重新启动一下, 还要去确认一下实际加载的是哪个版本的程序。接下来要往后翻回查从10月17日到现在的日志文件, 并且检查 Web 服务器所在的目录结构。通过以上的这些操作来排除已经受到黑客入侵或者恶意软件感染的情况存在的可能性。