披露要点：两处 CVSS 9.2 的未认证远程代码执行（PHP2Shell）
PHP 官方安全通告本轮一次性披露了两处内核高危缺陷，漏洞代号 PHP2Shell，CVE编号：CVE-2026-109618、CVE-2026-109619，CVSS v4.0 评分均为 9.2，级别属于严重（Critical）。两处问题都被归类为远程代码执行（RCE），并且具备同一个关键前提：攻击者不需要任何账号、登录态或后台权限，只要目标服务在网络上可达，就可以发起尝试。更值得注意的，是影响版本跨度：PHP 5.x、7.x、8.x 的多个分支都在受影响范围内，这意味着从仍在跑的 PHP 5.6 老站，到近两年新上的 PHP 8.x 项目，都需要回到官方通告里核对自己的具体子版本。
需要说明的是，“全系版本受影响”并不等于“每一台服务器都能被一键打穿”。这两处漏洞属于PHP内核内存缺陷，漏洞的可利用性与PHP 的运行模式（SAPI）和 Web 服务器配置强相关。同样是 PHP 7.4，跑在 mod_php 下和跑在 php-fpm、cgi 模式下，风险等级并不一样。判断自己是否在“高危区”，比单纯看版本号更重要；并且该漏洞和业务代码安全无关，业务代码再规范也无法抵御底层内核缺陷。
| 维度 | 情况说明 |
|---|---|
| 漏洞数量 | 两处，同一轮通告披露，统称PHP2Shell |
| CVSS 评分 | 9.2，严重（Critical） |
| 攻击前提 | 无需认证、无需账号，网络可达即可尝试触发 |
| 危害类型 | 远程代码执行，可能导致服务器被控制、数据被读取或篡改、Webshell 落地、横向渗透内网 |
| 影响版本 | PHP 5.4及以上、PHP7全系列、PHP8.0~8.5多个分支；8.2.35、8.3.36、8.4.27、8.5.12为官方修复版本 |
| 高风险部署 | Apache mod_php、Windows + Apache CGI/php-cgi、Nginx + PHP-FPM 且 location 匹配宽松、宝塔等面板一键环境、老版本CMS与商城系统 |
| 可能已被利用的迹象 | 访问日志出现异常超长请求头、畸形请求、站点目录出现陌生 PHP 文件、进程或定时任务被新增 |
两个漏洞的入口在哪里：攻击面拆解
从公开信息归纳，这两处缺陷的成因落在PHP内核内存处理层面，分别为OOM内存损坏、请求间残留全局状态引发释放后重用（Use-After-Free），漏洞不在业务代码本身。也就是说，即使你的项目代码写得很规范、做了代码层防护，只要底层PHP版本未修复，仍然存在被攻击风险。
入口一：CVE-2026-109618 OOM内存损坏RCE
PHP在解析请求数据过程中触发内存上限（memory_limit）时，异常跳转清理流程处理存在缺陷，造成内部内存结构损坏。攻击者通过构造特制请求，触发内存耗尽逻辑，篡改内部数据结构，最终实现远程代码执行。该攻击链在Apache mod_php环境下风险最高，可在业务脚本执行前完成利用。
入口二：CVE-2026-109619 跨请求全局状态残留（UAF）RCE
PHP-FPM等多请求复用进程的SAPI模式下，同一个进程连续处理多条HTTP请求，发生致命错误后部分全局状态没有正常重置清理，产生释放后重用漏洞。攻击者先后发送两组恶意请求，控制堆内存布局，达成代码执行效果，Nginx+PHP-FPM是该漏洞重点攻击场景。
这两条路径的共同点是：漏洞不在业务逻辑里，而在PHP运行内核本身。这也是为什么同一版本的 PHP，有的站点必须连夜处理，有的站点受配置限制风险相对可控，但是不存在可靠的永久临时补丁，升级是根治方案。
运行模式决定风险高低
企业在安排处置优先级时，先要弄清自己的站点跑在哪种模式下。可以直接在服务器上执行命令确认：
# 查看 PHP 版本 php -v # 查看运行模式（SAPI）：cli / apache2handler / cgi-fcgi / fpm-fcgi php -i | grep -i "Server API"
输出里的 Server API 就是判断依据。如果显示 apache2handler（mod_php），属于本次漏洞最高危场景；如果显示 cgi-fcgi，说明走的是CGI/FastCGI路径，需要重点核查；如果显示 fpm-fcgi，则要看 Nginx 的转发配置是否严格。
| 部署方式 | 与本次漏洞的关系 | 处置优先级 |
|---|---|---|
| Apache + mod_php | 高危，该环境下漏洞利用链成熟，攻击可优先触发 | 最高，优先升级、隔离 |
| Apache + CGI / php-cgi，或 Windows 下的 PHP 环境 | 支持触发漏洞利用链，黑产扫描重点目标 | 高，建议优先处理 |
| Nginx + PHP-FPM | 取决于 location 匹配与进程复用机制，配置宽松时极易被利用 | 配置宽松时为高，配置严格时风险明显下降，但仍建议升级 |
| 命令行 CLI 运行 | 不涉及Web请求解析，不受Web攻击链直接影响 | 一般不受本次问题直接影响，但升级仍建议同步进行 |
哪些业务系统大概率在名单里
从过往应急经验看，真正需要紧张的往往是以下几类资产：
公网可访问的官网与老站点，尤其是三五年以上没做过环境升级的项目，容易停留在 PHP 5.6 / 7.0 / 7.2 /7.4等已停止维护的分支，官方不会提供补丁。
基于开源 CMS 或框架搭建的站点，如 WordPress、Drupal、Laravel、ThinkPHP等，环境配置往往由当年的一键安装包决定。
托管在 Windows Server 上的 PHP 项目，这类环境更倾向使用 CGI模式，落在本次高风险区。
面板一键部署环境（宝塔、WDCP等），大量默认PHP7、PHP8.0、8.1，长期不关停、不更新，却能被公网扫到。
容器镜像与CI产物，基础镜像停留在旧版本，每次发布都在复制同一个风险。
现在就能做的五步排查
拉出 PHP 资产台账。把域名、服务器 IP、PHP 版本、SAPI 类型、使用的框架与 CMS 版本列成一张表，先解决“不知道自己有什么”的问题。
逐个确认运行模式。用上面的
php -i命令或 phpinfo 页面确认 SAPI，标记出mod_php、CGI/php-cgi 与 Nginx+PHP-FPM 的资产。核对官方通告中的受影响子版本。以 PHP 官方安全公告和 CVE 记录为准，确认自己的具体小版本是否落在范围内，不要凭“我装的是 8.x 应该没事”来判断。
排查是否已被尝试利用。检索 Web 访问日志中的超长请求头、畸形请求、可疑内存相关特征；检查站点目录是否出现最近修改的陌生 PHP 文件、WebShell。
确认备份与回滚能力。升级前先确认数据库、代码、配置有可用备份，避免修复动作本身引发业务中断。
# 在 Nginx 访问日志中检索可疑请求特征（示例，按实际日志路径调整） grep -Ei "longjmp|memory_limit|畸形头|%ad|%2e%2e" /var/log/nginx/access.log | head -30 # 查找站点目录中近 7 天内新增或修改的 PHP 文件 find /var/www -name "*.php" -mtime -7 -ls | head -30
这两条命令不能替代专业排查，但可以快速判断“是否已经有人在你门口试过”。如果日志里出现大量同类请求，说明目标很可能已经被黑产扫描器收录。
临时缓解：不动代码也能降风险
在正式升级窗口排期之前，可以先通过配置把攻击面收窄。以下措施属于缓解，不是修复，官方明确不存在完美的绕过阻断方案，升级仍需按计划完成。
| 配置位置 | 风险写法 | 建议调整 |
|---|---|---|
| Apache 模块 | 启用 mod_php 直接对外暴露 | 评估业务，优先迁移至FPM；无业务必要关闭mod_php |
| Nginx location | 仅写 location ~ \.php$，未限制PATH_INFO、脚本校验宽松 | 严格匹配脚本路径，配合 try_files 拦截不存在的文件 |
| php.ini | allow_url_include = On | 改为 Off，减少附加攻击链风险 |
| php.ini | session.upload_progress.enabled = On | 关闭上传进度会话，缩小UAF攻击面 |
| php.ini | expose_php = On | 改为 Off，减少版本信息外泄，规避定向扫描 |
| 网络层 | PHP-FPM 监听在 0.0.0.0:9000，公网可直达 | 改为仅监听 127.0.0.1 或内网地址 |
# Nginx + PHP-FPM 的收紧写法示例
location ~ \.php$ {
# 严格拆分脚本名与 PATH_INFO
fastcgi_split_path_info ^(.+\.php)(/.*)$;
# 脚本文件不存在直接 404，避免被拼出额外路径
try_files $fastcgi_script_name =404;
# 不向 PHP 透传 PATH_INFO，减少解析歧义
fastcgi_param PATH_INFO "";
# 关闭远程文件包含，覆盖全局配置
fastcgi_param PHP_ADMIN_VALUE "allow_url_include=Off;session.upload_progress.enabled=0";
fastcgi_pass unix:/run/php/php8.2-fpm.sock;
include fastcgi_params;
}此外，如果企业已有 WAF 或云防护，可以请厂商更新针对本次漏洞的拦截规则；但 WAF 属于兜底，不能当成不升级的理由——编码、内存层面的绕过手段一直在演进。
正式修复：升级路径与老系统的现实选择
真正的修复只有一条路：升级到官方发布的安全版本。需要注意两点现实问题：
PHP 5.6 以及 7.0～7.4、PHP8.0、8.1分支均已停止官方维护，官方不会再为这些版本发布补丁。继续停留在这类分支上，等于长期暴露在已知高危风险中。
从 PHP 5.x /7.x 直接跨到 8.x 通常伴随大量兼容性改造，包括被移除的函数、扩展、类型声明规则、框架与 CMS 版本要求等，直接替换二进制文件大概率会把站点打挂。
比较稳妥的做法是分两步：先做临时缓解把风险压下去，再按业务优先级排升级窗口，先在预发布环境完成兼容性验证，最后灰度切换并保留回滚路径。对于确实无法立刻升级的老项目，可以先隔离——限制公网访问、单独部署、加一层防护设备，把暴露面降到最低。
这类“老系统既要稳定运行、又要完成漏洞修复”的场景，通常需要连带做代码兼容性适配、扩展重装、接口回归验证，甚至顺带把老旧的接口对接方式和后台功能一并改造。尊云科技在处理 PHP 老项目升级、二次开发和接口对接方面有成熟流程，可以在不影响业务的前提下分阶段推进，规避升级引发的业务故障。
已经被打过的话，重点看这几处
Web 访问日志：异常超长请求头、畸形数据包、大量扫描PHP服务的陌生请求。
文件变化：站点根目录、上传目录、缓存目录中出现的陌生 PHP 文件，尤其是权限为 777 或属主异常的文件。
进程与定时任务：可疑的
crontab条目、非运维添加的系统服务、异常的外联连接、挖矿进程。账号与密钥：数据库账号、SSH 密钥、云 API 凭据是否被新增或改动。
数据库：是否存在被写入的异常内容、管理员账号是否被新增篡改。
如果确认已经被入侵，处置顺序应是：先隔离（断网、快照取证），再清理与修补，最后复盘加固。直接删掉 Webshell 就恢复上线，往往会二次沦陷。
长期治理：把“应急”变回“日常”
建立运行环境台账。域名、服务器、PHP 版本、SAPI、框架版本、负责人，一张表维护到底。
设定固定补丁窗口。安全通告定期订阅，重要漏洞设定响应时限，避免每次都靠临时通知紧急救火。
镜像与基线统一。容器基础镜像、面板环境模板统一版本，避免每次部署都复制旧风险。
关闭非必要暴露。测试环境、调试接口、PHP-FPM端口不对公网开放，能省掉大量噪音攻击。
定期做代码与环境审计。重点核查底层运行版本、服务配置，不能只做业务代码安全审计。
需要一起看的时候
如果你的站点数量较多、PHP 版本不统一，或者系统还停留在已经停止维护的分支上，可以先做一次针对性排查：理清资产与版本、确认运行模式、评估被利用痕迹，再决定是先做临时缓解还是直接排升级窗口。尊云科技（ZUNYUN.CC）提供网站建设、APP 与小程序开发、VUE 前端、PHP 开发、API 接口对接与二次开发等服务，也承接老系统升级与迁移，可以配合做版本自查、环境加固方案和升级改造的实施评估，帮助把改动控制在可回滚、可验证的范围内，保障网站业务安全稳定运行。