PHP2Shell 漏洞分析：PHP 7.2 如何防范？
我已阅读 Sansec 原文，并核对 PHP 官方公告、watchTowr 以及 CERT-EU 的安全通告。
核心结论：PHP 7.2 应按高危风险处理，而且这次不是普通的 PHP 网站代码漏洞，而是 PHP 解释器自身可能存在的远程代码执行（RCE）漏洞。
PHP2Shell 安全事件
| 漏洞编号 | CVE-2026-109618、CVE-2026-109619 |
| 严重程度 | CVSS 4.0：均为 9.2 分 |
| 漏洞类型 | 远程代码执行（RCE），依据安全研究机构报告 |
| PHP 7.2 | 疑似受影响，尚待官方确认具体范围 |
| 官方补丁 | 计划于 2026 年 10 月 21 日 14:00 UTC 发布 |
| PHP 7.2 官方维护 | 已于 2020 年 11 月 30 日结束 |
一、PHP2Shell 具体如何利用？
1. 目前公开的信息还没有披露完整的利用原理
这是首先需要明确的事情。
Sansec 的文章并没有提供漏洞的底层成因、触发参数、利用请求或完整 PoC。
PHP 官方也明确表示，技术细节、受影响版本和修复版本将在安全更新发布时一同公布。
目前可以确认或合理判断的是：
攻击目标是 PHP 运行环境，而不局限于 WordPress、Magento 或某个 CMS。
安全研究机构将其归类为远程代码执行，意味着成功利用后，攻击者可能以 PHP 服务进程的权限执行恶意代码。
公开泄露的 PHP2Shell 工具声称支持 PHP 5.4 及以上版本，但这个影响范围尚未得到 PHP 官方验证。
目前无法确认是否需要特定的 PHP 配置、扩展、请求方法或 Web 服务器组合才能触发漏洞。
The Hacker News+2
2. 为什么这个漏洞比普通的网站漏洞危险？
通常的网站代码执行漏洞，往往需要应用程序存在问题：
普通应用层代码执行漏洞
攻击者构造请求
网站业务代码处理不安全
触发代码执行
PHP2Shell 报告所指的风险
攻击者发送恶意 HTTP 请求
Web 服务器将请求交给 PHP
PHP 运行时自身的漏洞
实际触发机制尚未公开
可能实现远程代码执行
第二张图是根据当前风险报告绘制的概念模型，不是已经证实的完整利用链。
如果问题确实发生在应用业务代码执行之前，那么即使网站已经做了 SQL 注入过滤、XSS 过滤、上传限制、参数过滤，仍然可能受到影响。
Sansec 特别强调：不能依赖修改网站应用代码来修复，需要从 PHP 运行环境层面解决。
二、PHP 7.2 如何防范？
PHP 7.2 的最后一个官方版本是 7.2.34，已停止维护多年。即使安装了这个版本，也不能认为已经修复 PHP2Shell。
以下按照防护效果和实施优先级排序。
优先级 | 防护措施 | 对 PHP2Shell 的作用 |
|---|---|---|
P0 | 升级到官方已修复的 PHP 版本 | 根本修复方式 |
P0 | 给 PHP 7.2 应用经过验证的第三方回移补丁 | 可行，但必须验证补丁确实覆盖这两个 CVE |
P0 | 暂时隔离 PHP 网站的公网访问 | 显著降低远程攻击风险 |
P1 | 限制 Nginx / Apache 对 PHP 的访问 | 缩小可攻击入口 |
P1 | WAF / CDN 防护 | 辅助防护，暂时无法保证阻断 |
P1 | PHP-FPM 权限隔离 | 降低成功攻击后的损害 |
P2 |
| 纵深防御，不能当成漏洞修复 |
CERT-EU 也建议在无法及时修复时，考虑暂时隔离暴露于公网的应用。
方案 A：PHP 7.2 暂时无法升级
如果网站必须使用 PHP 7.2，最有效的临时措施是限制访问，而不是在 PHP 代码里增加过滤。
例如 Nginx 可以在对应站点的 server 配置中设置：
# 仅允许可信公网 IP 访问网站
allow 203.0.113.10;
deny all;这里的 IP 是示例，需要替换成你的管理 IP。
注意：这些规则需要被所有相关 location 正确继承；如果网站经过 Cloudflare 等代理，还需要正确配置可信代理和客户端真实 IP。更稳妥的方式是在云防火墙、安全组或 VPN 层限制公网入口。
验证 Nginx 配置：
sudo nginx -t
sudo systemctl reload nginx如果不能限制 IP，可以将风险最高的 PHP 站点暂时下线，改为静态维护页面。
方案 B：升级到仍受支持的 PHP 版本
目前 PHP 官方支持的稳定分支为 PHP 8.2、8.3、8.4 和 8.5。
需要强调：必须升级到包含本次安全修复的具体版本，而不只是随意安装一个 PHP 8.x。 截至核对时，官方尚未公布本次修复的准确版本号。
如果老程序无法直接升级到 PHP 8，我更建议先搭建独立测试环境迁移，而不是直接替换生产环境。
如果 PHP 7.2 无法替换，只能考虑获得可靠供应商提供的 PHP 7.2 长期维护补丁，确认其明确修复 CVE-2026-109618 和 CVE-2026-109619，并覆盖实际使用的 PHP-FPM、Apache 模块或其他运行方式。
方案 C：继续做 PHP-FPM 安全隔离
下面这些措施不能消除 PHP2Shell 漏洞，但能降低入侵后的影响。
例如把 PHP-FPM 限制为 Unix Socket，并使用权限有限的独立服务账户。
; PHP-FPM pool 示例，需根据实际服务配置调整
user = www-data
group = www-data
listen = /run/php/php7.2-fpm.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660不要以 root 身份运行 PHP 工作进程，也不要让不同网站共享同一个可写权限过大的执行账户。
同时，网站源代码原则上应对 PHP 服务账户只读，仅上传目录、缓存目录和必要的运行目录赋予写权限。
PHP 7.2 的 php.ini 还可以进行基础加固：
expose_php = Off
display_errors = Off
log_errors = On
allow_url_fopen = Off
allow_url_include = Off
disable_functions = exec,passthru,shell_exec,system,proc_open,popen其中 allow_url_fopen=Off 可能影响远程资源获取；disable_functions 可能影响依赖外部命令的程序。请先测试业务兼容性。
这些设置不是 PHP2Shell 的确认修复办法。 特别是如果漏洞发生在解释器底层，禁用 exec、system 并不能保证阻止攻击者执行代码。
三、如何检查自己的服务器是否暴露？
针对 Linux + Nginx / PHP-FPM，可以先检查实际运行环境。
查询命令行 PHP：
php -v检查正在运行的 PHP-FPM：
ps -eo pid,user,args | grep '[p]hp-fpm'查看 Nginx 实际交给哪个 PHP-FPM：
sudo nginx -T 2>/dev/null | grep -n 'fastcgi_pass'如果使用 Docker，也需要检查容器内部的 PHP 版本。php -v 显示的 CLI 版本未必就是网站实际使用的版本。
对于入侵排查，应重点关注 PHP-FPM 异常启动 shell 进程、意外外连、Web 目录中新出现的 PHP 文件和敏感配置被改动等现象。这些只能作为调查线索，不能单凭它们认定 PHP2Shell 已被利用。
四、能不能只通过修改 PHP 7.2 配置彻底防范？
目前没有经过确认、仅修改 php.ini 或应用代码就能彻底防范这两个漏洞的方法。
原因很简单：在漏洞触发机制尚未公开之前，我们无法确认它是否受某个配置参数、扩展或请求入口控制。
因此，不建议把关闭危险函数、拦截特殊 POST 请求、限制上传格式或部署普通 WAF 规则当作完整解决方案。
五、我的建议
如果是正在运行的 PHP 7.2 生产网站，我建议采用以下顺序：
第一阶段：立即降低暴露面。 限制不必要的公网入口，为站点和数据库制作可恢复备份，确认实际的 PHP 运行版本和服务管理方式。
第二阶段：获取真正的修复。 PHP 官方补丁发布后，核对技术细节；能迁移的项目升级到受支持的已修复版本，不能迁移的项目采用可信的 PHP 7.2 回移补丁。
第三阶段：验证。 检查服务加载的 PHP 版本、补丁包记录、网站兼容性及异常日志。不要仅凭版本字符串判断安全状态。
可以持续核对以下两处原始资料：
当前最重要的未知问题，是这两个漏洞到底通过 PHP 哪个内部组件触发，是否需要额外的服务器配置条件。一旦官方发布漏洞成因和修复差异，就能进一步判断 PHP 7.2 是否存在不升级解释器也能有效缓解的特定配置方法。
