无需登录、远程代码执行、最高风险级别之一。PHP 运行时安全问题，再次给所有网站运维人员敲响警钟。
📌 本文重点
- 漏洞到底是怎么产生的？
- 为什么 PHP 底层漏洞可能绕过应用层防护？
- 如何排查服务器上的所有 PHP 运行时？
- 暂时无法升级，应该采取哪些缓解措施？
- 如何判断服务器是否已经被入侵？
如果你负责网站运维、服务器安全、企业安全运营，或者正在维护 WordPress 等 PHP 应用，这篇文章值得收藏。
一、PHP 出现高危漏洞，为什么值得警惕？
2026 年 10 月 20 日，关于 PHP 高危漏洞的消息开始在安全社区传播。
随后，PHP 安全团队提前发布安全更新。根据本文所依据的材料，此次漏洞事件涉及两个 CVE：
🔴 CVE-2026-109618
🔴 CVE-2026-109619
原文给出的两个漏洞 CVSS 4.0 评分均为 9.2，风险涉及未认证远程代码执行。
这意味着，在满足相应利用条件的情况下，攻击者可能无需登录，就能通过构造请求触发 PHP 运行时中的安全缺陷。
真正危险的地方在于：问题并不一定出在网站的业务代码中，而可能存在于 PHP 运行时本身。
哪些系统需要重点排查？
不仅是普通 PHP 网站，还包括：
- WordPress、Drupal、Joomla 等 CMS 系统；
- 电商平台、营销活动页及企业内部后台；
- Apache + mod_php 部署环境；
- PHP-FPM、PHP-CGI 等运行环境；
- cPanel、Plesk 等主机管理面板；
- Windows 上捆绑 PHP 的第三方软件；
- 长期无人维护的遗留系统和外包网站。
需要说明的是，全球约 75% 的网站使用 PHP，并不意味着 75% 的网站都存在这两个漏洞。
真正需要关注的是：你的 PHP 运行时是否受影响，以及是否已经安装对应安全补丁。
二、漏洞原理：一次 HTTP 请求，为什么可能威胁整台服务器？
理解这次漏洞，需要先了解 PHP 处理请求的基本过程。
一次典型的 Web 请求，大致经历以下阶段：
接收请求 → 初始化运行环境 → 执行业务代码 → 清理资源 → 处理下一个请求
正常情况下，PHP 必须保证每个阶段的内存和状态都处于正确状态。
一旦异常处理或资源清理出现问题，就可能产生严重的内存安全漏洞。
01 CVE-2026-109618：内存耗尽引发的初始化异常
根据原文提供的技术分析，第一个漏洞与 PHP 处理内存耗尽的异常路径有关。
正常情况下，当内存不足时，程序应该安全地退出或进入错误处理流程，并正确清理已经创建的资源。
但如果初始化过程只完成了一部分，异常清理流程却把相关数据当成已经完整初始化的对象，就可能出现问题。
可以用下面的流程理解：
这类漏洞的关键，并不只是「内存不足」。
真正的问题是：
程序在异常退出时，没有正确保证对象状态和资源生命周期的一致性。
根据具体执行路径和内存状态，这类缺陷可能导致程序崩溃、内存破坏，甚至进一步引发代码执行。
02 CVE-2026-109619：经典的 Use-After-Free 问题
第二个漏洞涉及一种经典的内存安全缺陷：
Use-After-Free，简称 UAF，即释放后使用。
简单来说，就是程序已经释放了一块内存，却仍然保留着指向这块内存的引用。
当后续代码继续访问这个失效引用时，就可能出现严重问题。
其基本过程可以理解为：
为什么这值得重视？
因为 UAF 可能造成：
- 程序崩溃，影响业务可用性；
- 内存内容泄露；
- 内存状态被破坏；
- 在特定条件下进一步导致远程代码执行。
需要注意，UAF 并不意味着每次请求都会触发漏洞，也不意味着攻击者必然能够获得代码执行。实际影响取决于具体的内存布局、执行路径和运行环境。
03 为什么 mod_php 模式尤其值得关注？
原文特别提到，PHP 官方对 Apache 的 mod_php 模式给出了警示。
在相关攻击路径下，漏洞可能在应用程序代码执行之前被触发。
这意味着，问题可能发生在业务鉴权逻辑运行之前。
因此，以下措施不能被当成充分的修复方案：
❌ 只更新 WordPress 核心。
❌ 只升级业务框架。
❌ 只修复某个存在漏洞的业务接口。
❌ 只依赖 WAF 拦截攻击请求。
❌ 只增加后台登录验证。
真正的修复重点，是升级受影响的 PHP 运行时及其对应的软件包。
不同 PHP 版本、构建方式和运行模式的具体影响条件可能不同，仍需结合官方公告逐一确认。
三、第一件事：找到所有正在运行的 PHP
漏洞响应中，一个经常被忽略的问题是：
企业并不一定知道自己究竟运行着多少套 PHP。
除了正式业务服务器，还可能存在旧网站、测试环境、独立 PHP-FPM 服务以及第三方软件自带的运行时。
01 检查 PHP 版本
Linux 环境可以先执行：
php -v查看 PHP 配置文件：
php --ini检查相关进程：
ps -eo pid,ppid,user,args | grep -E \'php-fpm|php-cgi|httpd|apache2' | grep -v grep
但要注意：
php -v显示的版本，不一定就是 Web 服务实际使用的版本。
同一台服务器可能同时安装多个 PHP 版本，或者由 Apache 模块、PHP-FPM、容器及第三方软件分别管理。
因此，还需要进一步检查服务配置、进程路径、软件包来源和实际站点绑定关系。
02 检查已安装的软件包
Debian / Ubuntu：
dpkg -l | grep -i phpRHEL 系发行版：
rpm -qa | grep -i php检查常见 PHP 可执行文件：
command -v phpcommand -v php-cgicommand -v php-fpm
这些命令只能用于初步排查，无法保证发现所有手动安装、容器化或应用捆绑的 PHP。
03 不要遗漏这些环境
环境 | 重点检查内容 |
Linux 服务器 | PHP-FPM、PHP-CGI、Apache 模块 |
Windows 服务器 | php.exe、php-cgi.exe 及捆绑运行时 |
管理面板 | cPanel、Plesk 及面板管理的独立 PHP |
容器环境 | 运行中的容器、镜像仓库、旧镜像 |
CMS 网站 | WordPress、Drupal、Joomla 等 |
遗留系统 | 旧后台、活动页、无人维护的网站 |
云上托管环境 | 云厂商或主机商管理的 PHP 服务 |
建议为每项资产记录：运行版本、运行模式、是否暴露公网、维护责任方、修复状态及验证结果。
找不到负责人、无法确认版本的 PHP 资产，应优先排查。
四、正式修复：升级到经确认的安全版本
根据所提供的原始材料，PHP 于 2026 年 10 月 21 日发布了以下修复版本。
PHP 分支 | 原文所列修复版本 |
PHP 8.5 | 8.5.12 |
PHP 8.4 | 8.4.27 |
PHP 8.3 | 8.3.36 |
PHP 8.2 | 8.2.35 |
PHP 8.1 及更早版本 | 原文指出已不受 PHP 官方维护，应评估迁移至受支持版本 |
注意：以上版本号依据原文整理，实际操作前请核对 PHP 官方公告及发行版厂商的安全更新说明。
01 Linux 发行版用户
如果 PHP 通过系统软件仓库安装，建议优先使用发行版提供的安全更新包。
Debian / Ubuntu 可以先刷新软件包索引：
sudo apt-getupdateRHEL 系环境可以查询相关软件包更新：
sudo dnf check-update'php*'确认更新来源、软件包版本及依赖关系后，再按照生产环境变更流程升级。
特别注意：
部分 Linux 发行版会将安全补丁回移植到自身维护的旧版本分支，因此，版本字符串不一定与 PHP 上游版本完全一致。
判断是否修复，应以厂商安全公告、软件包发行版本和实际补丁状态为准，而不是只比较版本号。
02 源码编译安装的 PHP
如果 PHP 是通过源码编译安装的，需要确认：
- 实际使用的 PHP 源码版本；
- 安装目录及运行路径；
- 编译参数和扩展依赖；
- PHP-FPM、Apache 模块或 CGI 使用的二进制文件；
- 服务重启后实际加载的版本。
建议按照以下顺序处理：
获取修复版本 → 测试环境构建 → 验证扩展兼容性 → 部署生产环境 → 重启相关服务 → 验证实际运行时。
不要只替换一个 PHP 可执行文件，却遗漏 Apache 模块或其他独立运行时。
03 宝塔、cPanel、Plesk 等面板环境
这类环境经常同时运行多个 PHP 版本。
需要逐项确认：
- 每个站点绑定的 PHP 版本；
- 面板安装的全部 PHP 分支；
- PHP-FPM 服务实际启动路径；
- 旧版本是否仍被其他站点使用；
- 面板是否提供对应安全更新。
升级一个版本，不代表其他站点使用的版本也会同步升级。
04 Windows 环境
Windows 服务器上，PHP 可能被捆绑在其他软件中。
重点检查：
- php.exe；
- php-cgi.exe；
- Apache 加载的 PHP 模块；
- 应用目录内的独立 PHP；
- 第三方软件维护的运行时。
如果 PHP 来自第三方软件，应同时确认供应商是否提供修复版本。
05 旧版本怎么办？
对于已停止官方维护的旧 PHP 分支，建议制定迁移计划。
如果无法立即升级，应优先：
1. 关闭不必要的公网访问；
2. 限制管理入口和来源 IP；
3. 将服务放入受控网络；
4. 收紧进程权限和出站访问；
5. 明确迁移负责人及最终期限。
隔离只能降低风险，不能代替长期升级。
五、暂时不能升级？先做好这五项缓解措施
正式补丁是根本解决方案。
如果业务系统暂时无法升级，企业需要在修复窗口内尽量缩小攻击面。
措施一：关闭不必要的公网入口
对于测试环境、旧后台和非必要网站，可以暂时停止公网访问。
对于必须运行的业务，建议：
- 通过 VPN 或零信任入口限制访问；
- 通过防火墙限制来源 IP；
- 只允许指定反向代理访问后端；
- 关闭不需要的 CGI/FastCGI 入口；
- 将 PHP 服务限制在本机或受控内网。
如果攻击路径能够在业务代码执行前触发，仅关闭后台登录页面或增加业务鉴权并不足以解决问题。
措施二：通过网络边界降低风险
建议采用分层防护：
重点检查：
- 是否只开放必要的 HTTP/HTTPS 端口；
- PHP-FPM 或 FastCGI 是否被公网直接访问；
- 管理接口是否存在不必要的公网暴露；
- Web 服务是否能够访问过多内部系统；
- 是否具备必要的网络分区和出站访问控制。
需要明确：WAF 是补充防线，不是本次运行时漏洞的通用修复工具。
措施三：限制 PHP 进程权限
即使漏洞被利用，进程权限也会影响攻击者能够造成多大破坏。
建议检查：
- PHP 是否使用专用低权限账户运行；
- Web 目录是否存在不必要的写权限；
- 配置文件、密钥和备份是否暴露给 Web 进程；
- PHP 是否拥有不必要的管理员权限；
- 容器是否以 root 身份运行；
- 容器是否挂载宿主机敏感目录；
- PHP 是否拥有过宽的出站网络权限。
遵循最小权限原则，可以降低漏洞被利用后的影响范围。
但 open_basedir、disable_functions等 PHP 配置，并不是针对底层运行时漏洞的可靠通用修复方案。
措施四：监控异常进程行为
正常 PHP 服务通常有相对稳定的进程行为。
如果 PHP-FPM、PHP-CGI 或 Apache 进程突然启动不符合业务预期的命令解释器或下载工具，就应引起警惕。
重点关注：
- php-fpm 启动 bash 或 sh；
- php-cgi.exe 启动 cmd.exe 或 powershell.exe；
- Web 进程启动 curl、wget、nc 等工具；
- 业务进程出现异常外联；
- 进程命令行与日常业务行为明显不符。
Linux 环境可使用以下命令查看进程树：
ps -eo pid,ppid,user,lstart,args --forest需要注意，单次进程快照无法发现已经退出的异常进程。建议结合 EDR、进程审计、网络连接记录和业务基线进行持续监控。
措施五：限制出站访问和敏感资源访问
根据业务实际需要，限制 PHP 服务访问不必要的公网地址及内部系统。
同时检查：
- 数据库账户权限；
- 云平台访问凭证；
- 部署密钥和 API 密钥；
- 敏感配置文件的读取权限；
- 异常 DNS 查询及网络连接；
- 大规模、非正常的数据传输。
这些措施可以降低攻击者进一步横向移动或外传数据的风险，但不能替代漏洞修复。
六、如何判断服务器是否已经被入侵？
补丁已经安装，不代表此前没有发生攻击。
如果服务器长期暴露公网，或者出现异常进程和资源访问行为，应进行专项排查。
01 检查异常子进程
重点核对：
- 父进程及进程启动时间；
- 命令行参数；
- 运行用户；
- 可执行文件路径；
- 网络连接目标；
- 同一时间段的 Web 和 PHP 日志。
正常系统中也可能存在合法的 Shell 调用，因此不能仅凭出现 bash、curl 或 wget 就断定被入侵。
02 检查 WebShell 和异常文件
重点关注：
- 不在正式发布清单中的 PHP 文件；
- 被修改的入口文件；
- 伪装成图片或缓存的可执行脚本；
- 不明来源的隐藏文件；
- 被篡改的 CMS 核心文件；
- 异常修改的配置文件。
可以按最近三天修改的文件进行初步筛查：
find /var/www -type f -mtime -3 -print其中 `/var/www` 只是示例路径，应替换为实际网站根目录。
注意，该命令只能筛选近期修改的文件，不能证明这些文件是恶意文件，也不能发现所有后门。
03 检查持久化机制
建议检查：
- 系统及用户级计划任务；
- 异常 systemd 服务；
- 启动脚本；
- 新增账号及 SSH 授权密钥；
- Web 目录中的自动执行机制；
- 被停止的安全软件和日志代理。
排查时应优先保全证据，避免未经确认就删除文件或修改关键配置。
04 关联分析日志
建议同时检查：
- Web 访问日志；
- Web 服务器错误日志；
- PHP-FPM 或 PHP-CGI 日志；
- 系统认证日志；
- EDR 告警；
- DNS 和网络流量日志。
需要注意：没有明显的应用层异常记录，并不能证明服务器没有被利用。
对于运行时漏洞，还需要结合主机侧行为和持久化痕迹进行判断。
七、发现异常后，应该如何应急？
如果已经发现异常 Shell、未知外联或疑似 WebShell，应立即将事件升级为安全事件，而不是只做普通补丁更新。
建议按以下顺序处理。
第一步：隔离风险资产。
根据业务影响限制公网访问及内部通信，避免风险继续扩散。
第二步：保留证据。
保存进程信息、网络连接、Web 日志、系统日志、可疑文件和云平台审计记录。
如果存在重要的易失性证据，应由应急响应人员决定采集方式，避免贸然重启导致证据丢失。
第三步：修复漏洞并清除入侵痕迹。
升级 PHP 运行时，排查恶意文件、异常账号、计划任务和服务配置。必要时从可信镜像或干净备份重建系统。
第四步：轮换可能泄露的凭证。
重点处理数据库密码、云平台访问凭证、部署密钥、SSH 密钥和应用 API 密钥。
第五步：验证恢复结果。
确认运行时补丁生效、异常持久化机制已清除、业务功能正常，并恢复必要的监控与审计。
对于已经确认被入侵的主机，仅删除一个 WebShell，通常不足以证明环境已经恢复可信。
八、企业安全团队可以直接使用的检查清单
建议将以下事项纳入本次漏洞专项治理。
已盘点全部 PHP 服务器、容器及托管环境。
已确认实际 PHP 版本和运行模式。
已核对 PHP 官方公告及发行版厂商安全公告。
已完成受影响运行时的升级或补丁安装。
已检查面板环境、多个 PHP 版本及应用捆绑运行时。
无法立即升级的资产已限制公网访问。
已检查 PHP 进程的异常子进程和外联行为。
已排查 WebShell、异常文件、计划任务及新增账号。
已保全相关日志并检查可疑时间段的访问记录。
已评估可能泄露的凭证并完成必要轮换。
已完成业务验证和主机侧复测。
已为无法修复的遗留资产指定负责人和迁移期限。
建议优先处理已经出现异常行为的资产，其次是直接暴露公网且尚未修复的资产。
九、最后：漏洞修复的真正难点，是找到那些被遗忘的系统
php2shell 事件提醒我们，企业安全的短板未必是缺少某种高级防护产品，而可能是一些长期没有被纳入安全管理的基础设施。
一个旧网站、一套外包后台、一个管理面板里的独立 PHP 版本，都可能成为安全风险的入口。
面对这类运行时漏洞，企业真正需要完成的，不只是升级一次软件，而是建立完整的风险闭环：
资产发现 → 版本核查 → 补丁修复 → 风险缓解 → 入侵排查 → 恢复验证
现在，建议每个负责网站和服务器安全的人，都先回答三个问题：
第一，我们到底运行着多少套 PHP？
第二，这些 PHP 是否已经安装经确认的安全补丁？
第三，在补丁生效之前，有没有证据表明攻击已经发生？
如果这三个问题还没有明确答案，那么漏洞处置就还没有真正结束。
参考资料
- PHP 官方安全公告与发行说明：
https://www.php.net
- Huntress 技术分析：
https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities
- CERT-EU 安全公告：
https://cert.europa.eu/publications/security-advisories/2026-018
- 对应 Linux 发行版、云厂商及主机管理面板的安全公告。
发布说明：本文漏洞编号、原文所述技术成因、版本号及事件时间线依据所提供的原始材料整理，修复和应急流程属于防御性技术建议。发布前及实际操作前，应再次核验官方公告、版本对应关系和补丁状态。
END
推荐阅读
月下载9000万次的AI网关LiteLLM曝双漏洞：低权限账号就能偷走你所有API密钥
2026-10-20
3.5万次请求、翻找泄露密钥：失控AI智能体围猎高德地图，运营者却毫不知情
2026-10-19
51个AI代理，61秒植入32个后门：黑客已经把AI训练成红队主力
2026-10-16
黑客把冷柜调到50℃，数百家超市一夜报废：工控安全最扎心的一课
2026-10-15
7分钟加密3.6PB，运维7小时没找到勒索信：日本国家级云平台被黑全过程
2026-10-13
更多AI知识，请关注Aiker World社区