紧急预警：PHP 曝出两个严重远程代码执行漏洞（php2shell），用 PHP 的请立即升级

一句话结论：只要你的服务器上跑着对外提供网页的 PHP，就先去查版本。不是 8.5.12、8.4.27、8.3.36、8.2.35 或更新（或者你的系统没有打上对应的安全补丁），就今天升级，升级后还要重启 PHP 进程。PHP 官方说得很明确：没有任何临时办法能让你的服务器完全安全，升级是唯一彻底的解决方式。

本文整理的是 2026 年 10 月 30 日之前公开的信息，事情还在变化，以 PHP 官方公告为准（文末有链接）。我不写任何攻击细节，只讲怎么防。

发生了什么

漏洞是什么

这是 PHP 语言本身（核心）的两个漏洞，不是某个网站程序或插件的问题。PHP 官方给两个都打了 9.2 分（CVSS v4.0，满分 10）。

• CVE-2026-109618：内存不足（OOM）时，PHP 在请求处理到一半被打断，内部数据只初始化了一部分，后面的清理流程把这些无效数据当成了有效的，从而可能被利用来执行代码。
• CVE-2026-109619：一个请求用过的内部状态，在内存已经释放之后仍然被保留下来，同一个工作进程处理的下一个请求可能会用到这块已经失效的状态，同样可能导致代码执行。

最让人担心的几点：

• 不需要登录。攻击者发来一个网络请求就可能触发。
• 和你的网站代码写得好不好无关。官方说，在 Apache 的 mod_php 模式下，攻击甚至在你的应用代码运行之前就能发生。
• 范围极大。Palo Alto Networks 统计到公网上有超过 2260 万个可能受影响的 PHP 实例。

谁受影响

只要是对外处理网页请求的 PHP，都在范围里，包括：

• Apache + mod_php（官方评为风险最高）
• PHP-FPM（Nginx + PHP-FPM 最常见）
• php-cgi、FrankenPHP、LiteSpeed

还有几类人容易漏掉：

• PHP 8.1 及更早的版本：官方已经不再提供更新。CISA 的建议是：如果不能升级，就先下线。
• 别的软件里自带的 PHP：比如面板、虚拟主机后台、一些一键安装的网站套件。要去它们自己的更新里升。
• Docker 里的 PHP：镜像不会自动更新，要拉新镜像并重建容器。

现在就做：四步

第一步：查版本。 注意，命令行里的 php -v 不一定等于网站在用的那个 PHP，要分别查：

php -v                         # 命令行版本
php-fpm -v                     # PHP-FPM 版本（可能叫 php-fpm8.3 之类）
ps aux | grep -E 'php-fpm|apache2|httpd'   # 看看到底跑的是哪个
docker exec 容器名 php -v        # 如果用 Docker

第二步：升级。 以 Debian / Ubuntu 为例：

apt update
apt list --upgradable 2>/dev/null | grep -i php     # 看看有没有 php 的更新
apt install --only-upgrade 'php*'                    # 升级所有 php 包

• 注意版本号不一定变成 8.3.36。Debian、Ubuntu、RHEL 这类发行版会把补丁“移植”到旧的版本号上。判断有没有修好，要看更新日志里有没有这两个编号：

apt changelog php8.3-fpm | grep -E 'CVE-2026-10961[89]'

• 用第三方源（比如 ondrej/php、remi）的，更新这些源里的包即可。
• 用宝塔等面板装的 PHP，去面板里升级到对应的小版本，并确认升级后版本号变了。
• Docker 用户：拉取你用的那个大版本的最新镜像（比如 8.4 的最新），重建并重启容器，再进去 php -v 确认。

第三步：重启 PHP 进程。 这一步最容易漏。只升级不重启，正在运行的旧进程仍然是有漏洞的：

systemctl restart php8.3-fpm     # 服务名按你的版本改
systemctl restart apache2        # 或 httpd，如果用 mod_php

第四步：再查一遍。 重新查版本或更新日志，确认真的生效了。

暂时升级不了怎么办

官方给了几个降低风险的临时办法，但再强调一遍：这些不能让服务器真正安全，只是争取时间。

• 设置 memory_limit=-1（官方建议用 FPM 的 php_admin_value 或 Apache 配置来设），同时限制 post_max_size（没有上传功能设 8M，有上传设 32M，并且让 upload_max_filesize 小于它）。
• 设置 session.upload_progress.enabled=0，并重启所有 PHP 进程。要写在 php.ini、FPM 池配置或服务器配置里，不要用 ini_set() 或 .user.ini。
• 用 PHP 8.5 的话，再设置 fatal_error_backtraces=0 并重启。
• 用容器或 cgroup 限制内存可以，但不要用 RLIMIT_AS 和 RLIMIT_DATA。
• 前面挡一层 WAF（比如 Cloudflare）可以提供一些额外保护，但 CISA 也只说“可能提供一定的临时保护”。

如果这台机器既不能升级，又跑着 PHP 8.1 或更早，按 CISA 的建议：先把它下线。

怎么判断有没有被打

目前公开的信息里，攻击成功后常见的迹象是：PHP 的工作进程突然去开 shell 或下载工具。可以先看看这些：

ps -u www-data -o pid,ppid,etime,cmd              # www-data 换成你的 PHP 运行用户
ps -eo pid,ppid,user,cmd --forest | grep -A3 -E 'php-fpm|apache2|httpd'
find /var/www -type f -name '*.php' -mtime -7      # 最近 7 天被改过的 PHP 文件

正常情况下，PHP 进程下面不应该出现 sh、bash、curl、wget 这类子进程。再看看有没有陌生的定时任务（crontab -l、/etc/cron.d/）和陌生的登录。

如果怀疑已经被入侵：别只是升级了事。把它当成已经失陷的机器：保留日志、下线隔离，换掉服务器上所有的密钥、数据库密码和令牌，必要时重装系统。因为已经有人把这个漏洞和提权漏洞串起来拿到 root，所以“只清掉网站文件”不够。

另外两个相关的问题

CVE-2026-115560（目前没有完整补丁）：10 月 23 日 PHP 的公告提到，和 session 上传进度有关，存在一个“不太容易出现”的远程代码执行路径，完整说明会随下一个版本发布。需要同时满足两个条件：

1. 配置里的 session.serialize_handler 是 php_binary 或 php_serialize，而代码在 session_start() 之前用 ini_set() 把它改成了 php；
2. session 上传进度功能还开着。

如果你的程序从来没有在运行时改过这个设置，风险较小。保险起见，上面说的 session.upload_progress.enabled=0 先关掉，等官方修复版本出来再说。

CVE-2026-111497（仅 Windows）：PHP 官方 10 月 26 日更新了 Windows 版安装包（版本号后面带 -1，如 8.4.27-1），修复 Brotli 解压里的一个越界写入。只有在通过 cURL 扩展开启了“自动解压 HTTP 响应”时才会触到。用 Windows 跑 PHP 的，去官网重新下载。

我的服务器要不要紧

• 如果你的网站、面板、博客根本不用 PHP：不受这两个漏洞影响。比如本站官网用的是 Python，这个博客是纯静态文件。
• 但要留意服务器上有没有顺手装过 PHP 程序，比如 phpMyAdmin、某个探针、旧的 WordPress。它们也在用 PHP，一样要升。
• 不确定的话，直接在服务器上执行 which php php-fpm，有输出就要查。

参考来源

• PHP 官方安全公告（2026 年 10 月）
• CISA：Critical Vulnerabilities in PHP Require Immediate Patching
• Palo Alto Networks Unit 42：Threat Brief
• Huntress：Rapid Response, php2shell

漏洞的修复进度和攻击情况每天都可能变化。这篇文章会在有新进展时更新。