2026 年 10 月 21 日,PHP 项目针对两个严重漏洞 CVE-2026-109618 和 CVE-2026-109619 发布了紧急版本,这两个漏洞现被统称为 PHP2Shell。将两者串联利用,攻击者只需一个精心构造的 HTTP 请求即可在服务器上运行代码。攻击者无需登录,无需存在漏洞的插件,也无需任何错误配置。只要你服务器上的 PHP 在响应 Web 请求,在更新之前它就处于暴露状态。
攻击者在修复发布前几天就已在测试该漏洞,而大规模利用在版本发布后数小时内便已开始。安全研究人员估计,有 130 万至 190 万台面向互联网的主机受到影响。本指南将介绍这些漏洞是什么、哪些版本已修复、如何一步步修补私有服务器,以及如何检查是否有人抢在你之前入侵了系统。
要点速览
- PHP2Shell 是 PHP 中的两个严重漏洞(CVSS 9.2),只需一个 HTTP 请求即可实现无需认证的远程代码执行。
- 自 5.4 起的所有 PHP 版本,只要处理 Web 流量就会受影响,包括 mod_php、PHP-FPM、CGI、FrankenPHP 和 LiteSpeed。
- 已修复的版本为 8.2.35、8.3.36、8.4.27 和 8.5.12。更新后请重启所有 PHP 工作进程。
- 所有 WebGee cPanel 和托管 WordPress 服务器均已完成修补,客户无需任何操作。
- 漏洞在修复发布前就已被利用,因此即使已完成修补,也请检查日志和文件中是否有被入侵的迹象。
WebGee 客户:您已受到保护 我们的工程师已将所有 WebGee cPanel 共享主机和代理主机服务器,以及所有托管 WordPress 主机服务器升级到已修复的 PHP 版本,并重启了全部 PHP 工作进程。您无需任何操作。本指南适用于您自行管理的服务器,例如拥有 root 权限的 VPS、独立服务器或云服务器。
什么是 PHP2Shell?
PHP2Shell 是 PHP 核心请求处理中两个内存安全漏洞的统称。两者都位于你的应用(WordPress、Laravel、Magento 或其他任何程序)接收到请求之前就会运行的代码中。正因如此,即使你的 CMS 和插件保持最新,在这里也无法保护你。
CVE-2026-109618:请求解析期间的内存耗尽导致数据损坏
当 PHP 解析 multipart/form-data 请求体(表单和文件上传所使用的格式)时,如果中途内存耗尽,内部结构会处于半初始化状态。随后 PHP 的清理代码会把这种损坏状态当作有效状态处理。即使服务器的内存限制设置正常,精心构造的请求也能强制触发这一情况。
CVE-2026-109619:残留全局状态与释放后重用
PHP 使用 longjmp() 处理致命错误,它会直接跳出出错的代码而不进行栈展开。发生上述内存错误后,属于请求的全局状态可能仍指向已被释放的内存。由同一 PHP 工作进程处理的下一个请求随后便可能使用这块内存。研究人员已确认该漏洞可导致内存泄露和完整的远程代码执行。
两个漏洞结合起来,能将一个畸形的 POST 请求变成以 Web 服务器用户(www-data、apache 或 nobody)身份运行的 shell。攻击者随后可以读取你的 wp-config.php 和数据库凭据、植入后门、发送垃圾邮件,或进一步渗透你的网络。

漏洞有多严重?
- 严重程度:两个 CVE 均被评为 CVSS v4.0 9.2(严重)。早期公告中流传的评分为 10.0。
- 认证:无需认证。PHP 处理的任何 URL 都可触发该漏洞。
- 利用情况:已确认在野利用,且公开的概念验证代码正在流传。
- 受影响应用:已有针对 WordPress、Drupal、Joomla 和 Magento 的认证前代码执行演示。
- 存在时间:存在漏洞的代码路径可追溯到 PHP 5.4.0,因此非常老旧的服务器同样受影响。

哪些环境受影响?
所有处理 Web 流量的 PHP 安装,无论使用哪种服务器 API:
- 搭配 mod_php 的 Apache:风险最高,因为存在漏洞的解析过程直接在 Apache 工作进程内部运行。
- 位于 nginx、Apache 或 Caddy 之后的 PHP-FPM。
- php-cgi、FrankenPHP 和 LiteSpeed(LSAPI)。
仅用于命令行的 PHP(cron 任务、从不解析 HTTP 请求体的工作进程)无法被直接触达,但通常 Web 服务也安装了同一个二进制文件。请全部更新。
已修复的 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 7.4 至 8.1:没有官方版本。修复仅以源码向后移植补丁的形式提供,或通过 CloudLinux(alt-php)等厂商及部分 Linux 发行版获取。
- PHP 5.4 至 7.3:已停止支持,没有修复。请升级,或让网站脱离公网。

第 1 步:检查服务器运行的 PHP 版本
请同时检查命令行二进制文件和 Web 服务器实际使用的版本,两者往往并不相同。
# Command-line PHP
php -v
# Every PHP binary installed on the server
ls /usr/bin/php* /usr/sbin/php-fpm* /opt/cpanel/ea-php*/root/usr/bin/php /opt/alt/php*/usr/bin/php 2>/dev/null
# The version your web server serves: drop a temporary file, fetch it, then delete it
echo '<?php echo PHP_VERSION;' | sudo tee /var/www/html/v.php >/dev/null
curl -s https://your-domain.com/v.php; echo
sudo rm /var/www/html/v.php不要遗留 phpinfo() 文件 如果你使用 phpinfo() 或版本文件进行检查,用完后请立即删除。攻击者会扫描这类文件来识别存在漏洞的服务器。
第 2 步:修补服务器上的 PHP
请选择与你的平台对应的部分。更新后,你必须重启所有 PHP 进程。旧的工作进程在被替换之前会继续运行存在漏洞的代码。
Ubuntu 和 Debian
sudo apt update
sudo apt install --only-upgrade 'php*-common' 'php*-cli' 'php*-fpm' 'libapache2-mod-php*'
# Restart PHP-FPM (repeat for each installed version)
sudo systemctl restart php8.3-fpm
# Using mod_php? Restart Apache instead
sudo systemctl restart apache2
# Confirm
php -v如果你通过 ondrej/php PPA 或类似的第三方软件源安装 PHP,请先确认该软件源已发布修复版本,再认定自己已完成修补。
AlmaLinux、Rocky Linux 和 RHEL
sudo dnf clean all
sudo dnf upgrade 'php*'
# Restart PHP-FPM and the web server
sudo systemctl restart php-fpm
sudo systemctl restart httpd # or nginx
php -vcPanel 和 WHM 服务器(EasyApache ea-php)
cPanel 以 ea-php 软件包的形式提供 PHP。请一次性全部更新:
# CloudLinux / CentOS 7
yum clean all && yum update "ea-php*"
# AlmaLinux / CloudLinux 8, 9 and 10
dnf clean all && dnf upgrade "ea-php*"
# Restart PHP-FPM for all accounts, then Apache or LiteSpeed
/scripts/restartsrv_apache_php_fpm
/scripts/restartsrv_httpd
# Check each installed version
for p in /opt/cpanel/ea-php*/root/usr/bin/php; do echo -n "$p: "; $p -r 'echo PHP_VERSION, PHP_EOL;'; doneCloudLinux alt-php(PHP Selector)
CloudLinux 将修复向后移植到了每一个 alt-php 分支,包括 5.6 和 7.4 等已停止支持的版本。由于版本号不会变化,请查看软件包的变更日志,而不是 php -v:
yum clean all && yum update 'alt-php*' 'ea-php*' -y
# Confirm the fix is in the installed package (example: alt-php 7.4)
rpm -q --changelog alt-php74 | grep -m1 -i 'CVE-2026-109618'Docker 与容器
容器不会自动更新。请拉取已修补的官方镜像,然后重新构建并重新部署:
# Pin to a fixed release (or newer)
FROM php:8.3.36-fpm
# ...your existing build stepsdocker pull php:8.3.36-fpm
docker compose build --pull
docker compose up -d
# Confirm inside the running container
docker compose exec app php -v第 3 步:今天无法修补时的临时缓解措施
这些设置可以降低暴露风险,但无法修复漏洞。请仅在安排升级期间用它们争取时间,例如在没有修复可用的 PHP 7.3 或更早版本上。
加固 php.ini
该漏洞利用依赖于在解析过程中触及 PHP 自身的内存限制。在 PHP 层面禁用该限制(并在其他层面强制执行硬性限制,见下文)即可消除主要触发条件。上传进度跟踪是进入漏洞代码的另一条路径。
; /etc/php/8.3/fpm/conf.d/99-php2shell.ini (adjust the path to your version)
; Interim mitigation for CVE-2026-109618 / CVE-2026-109619
memory_limit = -1
session.upload_progress.enabled = 0
post_max_size = 1M
; PHP 8.5 only
fatal_error_backtraces = 0WordPress 等应用会在运行时自行提高 memory_limit。请在 PHP-FPM 池中锁定这些值,使代码无法覆盖它们:
; /etc/php/8.3/fpm/pool.d/www.conf
php_admin_value[memory_limit] = -1
php_admin_flag[session.upload_progress.enabled] = offmemory_limit = -1 务必搭配硬性限制 如果没有 PHP 内存限制,一个失控的脚本就可能耗尽服务器的全部内存。请改为在进程层面限制内存,例如为 PHP-FPM 服务设置 systemd MemoryMax 或设置容器内存限制,让内核而不是 PHP 来终止失控的工作进程。
# Cap PHP-FPM memory with systemd
sudo systemctl edit php8.3-fpm
# [Service]
# MemoryMax=2G
# Or, for Docker:
docker update --memory 2g --memory-swap 2g <container>在 Web 服务器上限制请求体大小
在 PHP 接收之前就拒绝过大的请求体。这能拦截公开漏洞利用中使用的大型构造载荷,但也会拦截合法的大文件上传,因此请只在确有需要的路径上提高限制。
# nginx: inside http {} or server {}
client_max_body_size 1m;
# Allow bigger uploads only where needed, e.g. the WordPress media uploader
location = /wp-admin/async-upload.php {
client_max_body_size 64m;
include fastcgi_params;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}# Apache: in the vhost or .htaccess (bytes)
LimitRequestBody 1048576然后重启所有 PHP 工作进程,确保没有任何进程仍持有损坏的状态:
sudo systemctl restart php8.3-fpm
sudo systemctl reload nginx # or: sudo systemctl restart apache2如果你的网站位于 Cloudflare 之后,请为此漏洞启用其托管 WAF 规则;Cloudflare 在免费套餐中也提供了相应防护。不过,请把 WAF 当作额外的防护层,而不是修补的替代方案。CERT-EU 还建议隔离无法立即修补的面向互联网的 PHP 应用。
第 4 步:检查是否已被入侵
漏洞利用在大多数人来得及修补之前就已开始,因此完成更新并不意味着工作结束。请留意以下迹象。
出现在第 0 行的内存耗尽错误
无论攻击尝试成功与否,都会留下一条没有真实文件名和行号的致命内存错误,通常紧挨着一个异常大的 POST 请求:
sudo grep -R "Allowed memory size of .* exhausted .* in Unknown on line 0" \
/var/log/php*-fpm.log /var/log/apache2/error.log /var/log/httpd/error_log \
/var/log/nginx/error.log 2>/dev/null | tail -n 50工作进程崩溃
# Apache children dying with segfaults
sudo grep -R "AH00052: child pid .* exit signal Segmentation fault" /var/log/apache2/ /var/log/httpd/ 2>/dev/null
# PHP-FPM workers killed by signals
sudo grep -R "exited on signal" /var/log/php*-fpm.log 2>/dev/null由 Web 服务器用户启动的 shell
# A shell running under apache, www-data or php-fpm is a red flag
ps aux | grep -E "(apache|www-data|php-fpm|nobody)" | grep -E "\b(sh|bash|dash)\b" | grep -v grep
# Unexpected outbound connections from the web user
sudo ss -tunp | grep -E "php|apache|httpd|nginx"后门与持久化
# PHP files changed in the last 7 days
sudo find /var/www -type f -name "*.php" -mtime -7 -printf "%TY-%Tm-%Td %TH:%TM %p\n" | sort -r | head -n 50
# PHP files in upload folders (they should never be there)
sudo find /var/www -path "*uploads*" -name "*.php"
# Cron jobs added for the web user
sudo crontab -u www-data -l 2>/dev/null; sudo crontab -u apache -l 2>/dev/null在访问日志中,查找表单字段名极长(超过 1 MB)、请求体中含有二进制或空字节,或形如 =[binary]&a=1&[long field][x]=1 的 POST 请求。
成功的漏洞利用并不总会导致崩溃,因此日志干净并不能证明你是安全的。如果发现上述任何迹象,请按已被入侵处理:
- 将网站下线或切换到维护模式;
- 轮换数据库密码、API 密钥和 WordPress 盐值;
- 从 2026 年 10 月 17 日之前的备份中恢复;
- 完成修补后再让网站重新上线。
PHP2Shell 应对清单
- 找出服务器上的所有 PHP 版本,包括 CLI 和 Web
- 升级到 8.2.35、8.3.36、8.4.27、8.5.12 或厂商的向后移植版本
- 重启 PHP-FPM、Apache 或 LiteSpeed,确保没有旧工作进程残留
- 使用已修补的镜像重新构建并部署容器
- 对暂时无法修补的环境应用临时 php.ini 设置和请求体大小限制
- 在日志中搜索第 0 行内存错误和段错误
- 检查 Web 用户启动的 shell、新增的 PHP 文件和新增的 cron 任务
- 如有任何可疑之处,立即轮换凭据
为什么这类事件屡屡发生,托管主机又能如何帮忙
PHP2Shell 从蜜罐首次捕获到大规模利用不到一周,而其中大部分时间修复都还没有发布。对于自行运营服务器的企业来说,要防御这类威胁,就需要有人全天候关注安全情报、测试更新,并在补丁发布的第一时间将其推送到每个 PHP 版本和每个工作进程。而这往往需要在凌晨 2 点、在周末、在公开的漏洞利用已被大肆使用时完成。
这正是我们团队为 WebGee 客户所做的工作。针对 PHP2Shell,我们的工程师:
- 为所有 cPanel 共享主机和代理主机服务器部署了已修复的 PHP 版本;
- 将所有托管 WordPress 主机服务器更新到最新的已修补 PHP;
- 重启了所有 PHP 工作进程,确保没有存在漏洞的进程仍在运行;
- 以上所有操作均无需客户参与。
除了及时修补,WebGee 主机还提供服务器级恶意软件扫描、Web 应用防火墙和每日备份。即使攻击在某处得手,你也有干净的还原点可用。
如果你在需要自行修补的服务器上运行 WordPress、WooCommerce 或其他 PHP 应用,不妨考虑把这些工作交给我们。我们将免费为你迁移网站,全程零停机。
更想自己管理服务器?
如果你需要 root 权限,WebGee 云服务器让你拥有完全的控制权,我们的支持工程师也可以协助你修补、加固和监控服务器。如果你的网站只需要保持快速和安全,托管 WordPress 主机和 cPanel 云主机会为你自动保持 PHP 最新。不确定哪种方案适合你?联系我们的团队。
常见问题
我的网站托管在 WebGee,需要做什么吗?
不需要。我们已将所有 WebGee cPanel 共享主机和代理主机服务器,以及所有托管 WordPress 主机服务器升级到已修复的 PHP 版本,并重启了全部 PHP 工作进程。如果你自行运营拥有 root 权限的云服务器或独立服务器,请按照本指南中的步骤操作,或联系我们的支持团队寻求帮助。
更新 WordPress 或插件能修复 PHP2Shell 吗?
不能。漏洞存在于 PHP 本身,在 WordPress 或任何其他应用代码运行之前就会被触发。你必须更新服务器上的 PHP 软件包并重启 PHP。
哪些 PHP 版本修复了 CVE-2026-109618 和 CVE-2026-109619?
PHP 8.2.35、8.3.36、8.4.27 和 8.5.12,或任何更新的版本。PHP 7.4 至 8.1 仅有源码向后移植补丁和厂商构建版本(如 CloudLinux alt-php)。PHP 5.4 至 7.3 没有修复。
我用的是没有修复的旧版 PHP,该怎么办?
请尽快升级到受支持的 PHP 分支。在此之前,请应用本指南中的临时 php.ini 设置和请求大小限制,将网站置于 WAF 之后,或使其脱离公网。CloudLinux alt-php 也为许多已停止支持的版本提供了向后移植的修复。
只用 Web 应用防火墙够吗?
不够。WAF 可以拦截已知的利用模式,为你争取时间,但攻击者会不断变换载荷。修补 PHP 才是唯一真正的解决办法。
如何判断服务器是否已被入侵?
留意“Allowed memory size ... in Unknown on line 0”错误、发生段错误的工作进程、以 Web 服务器用户身份运行的 shell、最近被修改的 PHP 文件、上传目录中的 PHP 文件以及新增的 cron 任务。成功的攻击可能不会导致任何崩溃,因此如有疑虑,请轮换凭据,并从 2026 年 10 月 17 日之前的备份中恢复。
