PHP2Shell 高危漏洞科普：CVE‑2026‑109618/109619，为什么全球开发者连夜打补丁
前言
2026‑10‑21，PHP 官方紧急披露一组代号PHP2Shell的超高危远程代码执行漏洞，对应两个 CVE 编号：CVE‑2026‑109618、CVE‑2026‑109619，CVSS v4.0 评分达到 9.2 分，属于最高级别安全风险腾讯云。
和常见的网站 SQL 注入、文件上传漏洞不一样，这组问题出在PHP 底层解释器内核，不是业务代码 Bug。哪怕你的网站业务代码完全没有漏洞，只要使用受影响的 PHP 版本对外提供 Web 服务，未经登录的外部攻击者就有可能发送特制请求，实现远程代码执行，接管服务器控制权php2shell....。大量 WordPress、Drupal、Laravel、各类企业后台、商城、博客、宝塔 / CPanel 面板、Docker 容器环境均受到波及，全球运维、开发者连夜升级修复。
提示：本文基于 PHP 官方、云厂商公开安全通告整理，仅做科普，不替代正式安全处置方案。
一、漏洞原理：内核内存缺陷，无需登录即可攻击
两个漏洞都属于内存安全类缺陷，可以配合触发远程代码执行 RCE阿里云帮助...：
[*]CVE‑2026‑109618（OOM 内存耗尽损坏）攻击者构造特殊 multipart POST 请求，触发 PHP 内存耗尽 OOM。部分请求内存还没有完成初始化就被终止，后续清理流程错误把未初始化的残留内存当作合法数据处理，造成内存损坏，进而执行恶意代码。在Apache mod_php模式下，攻击甚至可以发生在业务 PHP 代码运行之前，业务层防护完全拦不住腾讯云。
[*]CVE‑2026‑109619（释放后重用 Use‑After‑Free）PHP 工作进程处理完一个请求之后，部分全局状态内存没有彻底清空重置。下一次 HTTP 请求到来，还能读取已经被释放的旧内存残留，造成内存泄露或者代码执行风险南通大学网...。
关键特点：
[*]无需账号密码，未认证远程攻击；
[*]漏洞根源在 PHP 内核，网站业务写的再完美也无法免疫；
[*]攻击只需要构造特殊 HTTP 请求，不需要上传文件、不需要后台登录；
[*]受影响运行环境：PHP‑FPM、Apache mod_php、php‑cgi、LiteSpeed、FrankenPHP 等 Web 服务模式全部中招，其中 mod_php 风险最高。
官方修复版本：8.2.35、8.3.36、8.4.27、8.5.12，低于以上版本均存在风险，PHP8.1 以及更早版本已经停止官方维护，没有官方补丁，建议整体升级大版本。
二、漏洞成功利用之后会造成哪些危害
[*]远程任意代码执行：攻击者以 Web 进程权限运行系统命令，直接接管服务器；
[*]敏感配置泄露：读取数据库账号、Redis 密码、API 密钥、云服务凭证等配置文件；
[*]植入 WebShell 后门：在网站上传、缓存、临时目录写入后门文件，实现长期驻留控制；
[*]业务数据篡改：篡改订单、用户、文章等业务数据；
[*]内网横向移动：如果服务器可以访问内网数据库、缓存、内部服务，被攻陷之后会成为入侵跳板；
[*]大规模批量扫描：漏洞公开之后，互联网会迅速出现公开扫描与 EXP 脚本，公网暴露的服务器会被批量探测，留给修复的时间窗口很短。
一个很形象的比方：业务代码是房间里的家具，WAF 是防盗纱窗，而 PHP 解释器是整栋房子门锁。门锁底层本身出问题，再坚固的家具和纱窗都挡不住入侵者。
三、排查大坑：不要只敲php -v就判定修复完成
服务器上经常存在多套 PHP 并存，很多运维踩坑：命令行php -v显示新版本，但对外 Web 服务实际跑的 PHP‑FPM 还是旧漏洞版本。
需要逐一确认这些位置的实际运行版本：
[*]Nginx/Apache 对接的PHP‑FPM 进程真实版本（网页访问 phpinfo 查看，不要只看终端命令行）；
[*]宝塔、cPanel 等主机面板，不同站点绑定独立 PHP 版本；
[*]Docker 容器内部 PHP 版本，容器镜像即便主机已经打补丁，容器内部依然可能是旧漏洞镜像；
[*]测试站、备用后台、遗留老项目，很多被遗忘的站点使用独立 PHP 环境；
[*]Linux 软件源、云市场镜像自带的 PHP 运行环境。
简单理解：就像一栋大楼，不能只检查大门口一把锁，地下室、后门、员工通道、各个隔间门锁都要检查一遍。
四、完整处置步骤
1、优先升级补丁（唯一根治方案）
[*]物理机 / 虚拟机：通过系统包管理器升级 PHP，升级完成后重启 PHP‑FPM、Apache/Nginx 相关 Web 进程，必须确认 Web 加载的是修复后版本，仅仅磁盘替换二进制文件，旧常驻进程依旧是漏洞版本。
[*]主机面板（宝塔等）：在面板后台更新对应 PHP 版本，每个站点绑定的 PHP 都要确认。
[*]Docker 容器：拉取官方修复镜像，--pull --no‑cache重新构建镜像，重新部署容器，旧容器直接销毁，不能只在运行容器内打补丁。
[*]已经停止维护的旧版本（PHP8.1 及更早）：没有官方补丁，建议升级到受支持的 PHP 大版本。
⚠️重要：升级不等于万事大吉。有可能在打补丁之前服务器就已经被入侵，必须同步做入侵排查。只换锁，不检查屋内有没有藏入侵者，风险依旧存在。
2、临时缓解手段（不能替代打补丁，仅应急过渡）
如果业务暂时无法立刻升级版本，可以做多重防护降低被利用概率，但无法彻底根除漏洞：
[*]公网限制：非业务必需接口，限制可信 IP 访问；
[*]WAF 规则：加载针对 multipart 异常 POST 请求防护规则；
[*]收紧权限：降低 PHP 运行进程系统权限；上传、缓存目录禁止执行脚本；
[*]关闭不需要的调试页面，删除 phpinfo 测试文件；
[*]加强 Web 访问日志、系统日志监控。
注意：所有缓解措施只是挡泥板，只要内核版本没有更新，就依然存在被绕过风险。
3、入侵痕迹排查（升级补丁之后必须执行）
重点检查：
[*]Web 访问日志、PHP 错误日志、系统安全日志，大量异常 POST、异常 User‑Agent 请求；
[*]Web 目录、上传目录、临时缓存目录：陌生 PHP 脚本、图片伪装脚本，重点看文件修改时间异常的文件；
[*]系统层面：可疑计划任务、新增系统账号、SSH 异常公钥、异常外联网络连接；
[*]数据库：新增不明管理员账号。
一旦确认或者高度怀疑被入侵：
[*]隔离主机，保留日志证据；
[*]轮换全部密钥：数据库密码、Redis 密码、后台密码、API 密钥、云账号访问凭证，即使密钥没有被直接使用，只要服务器沦陷就应当视作已经泄露；
[*]不能仅仅删除 WebShell 文件，攻击者可能预埋多处后门、计划任务，建议条件允许直接重建服务器环境。
五、给企业与站长的长期启示
PHP2Shell 给整个行业敲响警钟：安全防护不能只盯着 SQL 注入、文件上传这类业务层漏洞。底层运行时、解释器、容器镜像、第三方组件的安全更新同样生死攸关。很多团队业务安全做的很完善，却忽略底层依赖，一旦内核爆出高危漏洞，全部业务直接暴露风险。
建议建立常态化安全机制：
[*]建立资产台账，记录所有 Web 服务实际运行版本，区分命令行与 Web 环境；
[*]订阅 PHP、操作系统、容器镜像官方安全公告；
[*]重要业务具备补丁升级、灰度发布、回滚预案；
[*]开启文件完整性监控，最小权限原则配置 Web 进程权限；
[*]定期做入侵检测演练。
六、大众 & 运维常见认知误区澄清
误区 1：我网站业务代码没有漏洞，就不会受 PHP2Shell 影响。纠正：漏洞属于 PHP 内核，HelloWorld 最简站点同样会中招，和业务代码安全无关。
误区 2：终端执行php -v显示新版本，服务器就修复完毕。纠正：命令行 PHP 和 Web PHP‑FPM 是两套独立环境，务必通过网页 phpinfo 确认 Web 实际运行版本。
误区 3：开启 WAF、限制上传就可以彻底防御该漏洞，不用升级 PHP。纠正：WAF 属于缓解手段，存在被绕过可能性，升级官方补丁才是根治方案。
误区 4：Docker 主机系统打补丁，容器内部就自动修复。纠正：容器镜像内部拥有独立 PHP，主机升级不改变容器内部版本，需要重建镜像重新部署。
误区 5：漏洞只影响 WordPress、Drupal 这类 CMS，自研 PHP 系统不受影响。纠正：只要 Web 使用受影响 PHP 版本，无论什么业务系统都存在风险。
误区 6：打完补丁就完事，不需要排查入侵痕迹。纠正：漏洞公开到你打补丁的窗口期，服务器有可能已经被攻陷，只升级不排查等于留下后门。
结语
PHP2Shell 是一次典型底层组件高危漏洞。它提醒所有运维、开发者：安全防护不能只盯着应用层业务漏洞，编程语言内核、运行环境、容器镜像这些底层基础设施，一旦爆出严重缺陷，所有上层业务都会面临巨大威胁。
面对这类漏洞标准流程：先确认真实运行版本，尽快升级官方补丁，重启 Web 服务，完成入侵痕迹排查，轮换所有可能泄露凭证。临时缓解手段只能用来应急过渡，不可当做长期解决方案。
页:
[1]