收到阿里云 PHP php2shell 漏洞短信怎么办？CVE-2026-109618 / 109619 自查与升级指南

最近不少人收到阿里云发来的短信，提醒 PHP 爆了两个严重远程代码执行漏洞，外号叫 php2shell。如果你的 ECS、宝塔面板或 Docker 里还跑着 WordPress、Laravel、ThinkPHP 这类站点，别慌，先确认版本，再尽快升级。

这篇文章按「查版本 → 升级 → 重启验证 → 临时防护」的顺序写，方便直接照着做。

这是什么漏洞

2026 年 10 月 21 日，PHP 官方披露了两个严重漏洞，CVSS v4.0 评分约 9.2：

CVE-2026-109618：内存不足（OOM）处理有缺陷，请求清理时可能把未初始化的内部数据当有效数据用，最终可导致远程代码执行。
CVE-2026-109619：部分全局状态在请求结束后没有正确复位，或复位后又被写回，后续请求可能访问已释放的内存（use-after-free），可导致远程代码执行，也存在内存泄露风险。

关键点在于：攻击者通常不需要登录，只要能向你的站点发特制 HTTP 请求（常见是 multipart POST），就有机会在 PHP 引擎层触发，甚至在你的业务代码真正跑起来之前。Apache mod_php 风险最高，PHP-FPM、php-cgi、FrankenPHP、LiteSpeed 等所有对外提供 Web 服务的 PHP 环境都在影响范围内。

公开资料里已经有 PoC，也有利用尝试的报告。WAF / 云防火墙只能当临时挡板，不能代替升级。

谁需要立刻处理

只要机器上有「对外提供网页服务的 PHP」，就该优先处理，例如：

ECS / 轻量服务器上的 WordPress、Typecho、Discuz、Laravel、ThinkPHP
宝塔、CloudPanel、HestiaCP 等面板安装的 PHP 站点
Docker / K8s 里的 PHP 镜像与 PHP-FPM 容器
Apache 直接挂 mod_php 的站点

纯命令行脚本、本地开发环境、不对外开放的内网工具风险相对低，但仍建议一并升到补丁版本，避免以后误暴露。

先查清楚自己跑的是哪个 PHP

别只看 php -v。命令行 PHP 和网站实际用的 PHP 经常不是同一个。

常见自查方式：

# 命令行版本（仅供参考）
php -v

# PHP-FPM 常见进程
ps aux | grep php-fpm | grep -v grep

# Apache mod_php
apachectl -M 2>/dev/null | grep php
# 或
httpd -M 2>/dev/null | grep php

更靠谱的做法是：在网站根目录临时放一个只含 <?php phpinfo(); 的文件，用浏览器打开看「PHP Version」，看完立刻删掉。宝塔用户也可以在「软件商店 → PHP → 设置」里看当前版本号。

官方已修复的版本：

PHP 8.5.12 及同分支更新版本
PHP 8.4.27 及同分支更新版本
PHP 8.3.36 及同分支更新版本
PHP 8.2.35 及同分支更新版本

PHP 8.1 及更早版本官方已停止常规安全支持，不会再发上游补丁。部分发行版 / LTS 厂商可能有 backport，需要对照厂商安全公告；阿里云 Linux 已发布相关 SA（例如 Alinux 4 的 ALINUX4-SA-2026:0503），用发行版包时以厂商公告和包修订号为准。

各环境怎么升级

升级前先备份站点文件和数据库。能先在测试环境验证更好。

Debian / Ubuntu（apt）

先更新软件源，再升级 PHP 相关包（包名按你实际安装的改，例如 php8.3-fpm）：

sudo apt update
sudo apt install --only-upgrade php8.3-fpm php8.3-cli php8.3-common
# 如果用 Apache mod_php，再升级对应 libapache2-mod-php8.3
sudo systemctl restart php8.3-fpm
# Apache 用户
sudo systemctl restart apache2

用 ondrej/php 这类 PPA 的，确认仓库已同步到上述补丁版本后再升。

RHEL / CentOS / Alibaba Cloud Linux（yum / dnf）

sudo dnf clean all
sudo dnf update php php-fpm php-cli
# 或 yum update php php-fpm php-cli
sudo systemctl restart php-fpm
sudo systemctl restart nginx   # 或 httpd

Alibaba Cloud Linux 用户请同时查看 ALAS 公告，确认本机 PHP 包是否已包含 CVE-2026-109618 / 109619 的修复。

宝塔面板

面板里打开「软件商店」→ 找到正在用的 PHP 版本
能直接升级到补丁小版本就升级；升不了就换成同大版本里已打补丁的 PHP，或换到 8.2 / 8.3 / 8.4 / 8.5 的补丁版
升级后在「服务」里重启该 PHP，再重启 Nginx / Apache
用 phpinfo 或站点探针再确认一次版本号

面板只升了「软件商店里的 PHP」，不代表网站虚拟主机已经切到新版本。去网站设置里核对「PHP 版本」下拉框。

Docker / 容器镜像

# 示例：重建并换用官方补丁镜像标签
docker pull php:8.3.36-fpm
# 或 php:8.4.27-fpm / php:8.5.12-cli 等
docker compose up -d --force-recreate

自己打的镜像，要把 Dockerfile 里的 PHP 基础镜像改到补丁版，重新 build，再滚动替换旧容器。只 docker restart 旧镜像不够。

ECS 上的 WordPress

WordPress 本身不是漏洞根因，根因是底下的 PHP。处理顺序建议是：

快照或备份整机 / 站点
按上面系统或面板方式升级 PHP
重启 php-fpm / Apache
登录后台随便打开一篇文章，确认站点正常
再查一遍 PHP 版本

如果暂时升不了 PHP，至少给站点套上 WAF，并限制管理后台来源 IP。

升级后务必重启并复核

补丁装上不等于已经生效。所有处理 Web 请求的 PHP worker 都要重启或替换，例如：

sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2
# 容器环境：重建 / 滚动替换，不要只 restart 旧容器

然后再次用 phpinfo、面板版本页或 php-fpm -v 确认真正对外服务的进程已经是补丁版本。多版本共存的机器，特别容易「命令行升了，网站还在用旧的」。

暂时升不了时的缓冲措施

这些措施都不能替代升级，只能争取一点时间：

打开阿里云 WAF / 云防火墙（或其他厂商 WAF），确认域名流量确实经过防护，并关注攻击日志
在 Web 服务器或反代层限制请求体大小、multipart 段数、上传数量和嵌套深度
业务完全不需要 multipart 表单时，可在进 PHP 前拦截这类请求
针对 CVE-2026-109618：管理员可考虑临时设置 memory_limit=-1 并重启全部 PHP worker，同时评估资源耗尽风险；注意进程池 / 目录配置不要又把有限内存限额写回去。这不能覆盖底层分配失败场景
针对 CVE-2026-109619：管理员可考虑设置 session.upload_progress.enabled=0；PHP 8.5 还可考虑 fatal_error_backtraces=0。这些必须在请求解析前生效，并重启全部 worker，不要依赖应用里的 ini_set() 或 .user.ini
PHP-FPM 可在评估性能后设置 pm.max_requests=1，降低跨请求状态复用
实在来不及修、又高度暴露的站点，宁可临时下线或只允许白名单 IP 访问

官方也明确说了：不要指望 RLIMIT_AS / RLIMIT_DATA，也不要以为关掉错误输出就安全了。

升级后还要盯一会儿

看 Web 访问日志、WAF 拦截日志里是否有异常 multipart / 高频探测
看 PHP-FPM / Apache 错误日志有没有异常崩溃、段错误
留意机器上是否冒出陌生 PHP 文件、可疑进程、异常外连
阿里云用户可用安全中心核对主机软件指纹，确认资产清单和真实对外 PHP 版本一致

如果已经怀疑被打穿：先隔离机器，保留证据，再清理后门和重建服务，不要只「杀个木马」就继续上线。

参考链接

收到短信不是吓你，是提醒该动手了。先查版本，再升级并重启 worker；WAF 可以开着，但别把它当成终点。