一个只读的分诊脚本，用于在 PHP2Shell（CVE-2026-109618 和 CVE-2026-109619）之后检查 WordPress 站点。PHP2Shell 是 2026 年 10 月 21 日披露的 PHP 引擎中的一对严重远程代码执行漏洞。
修补 PHP 可以关闭这扇门，但 Amazon 的蜜罐记录到了一次利用尝试发生在 10 月 17 日，即公开披露前四天，当时这些漏洞仍处于禁运状态。这是目前任何人公开的最早活动，而不是攻击开始的那一天，因此应将其视为下限。在该时间窗口内，任何在未修补的 PHP 上可访问的站点可能已经存在后门，而更新 PHP 并不会将其移除。此脚本检查一个或多个 WordPress 站点，查找具有代码执行能力的攻击者通常会留下的痕迹，并为每个站点生成一份 Markdown 报告。
第三个漏洞 CVE-2026-115560 于 10 月 23 日公布。它目前还没有修复版本：10 月的点版本（8.2.35、8.3.36、8.4.27、8.5.12）并未涵盖它，修复预计随 11 月的下一次常规版本发布。php.net 要求所有人在此之前于 php.ini 或 PHP-FPM 池中设置 session.upload_progress.enabled=0。脚本会检查是否已完成该设置。
它从不修改或删除任何内容。它只列出、验证并报告。如何处理发现的问题由你决定。
| 领域 | 检查项 |
|---|---|
| PHP | 已安装的 CLI 版本与修复版本（8.2.35、8.3.36、8.4.27、8.5.12）的对比。标记已终止支持的分支，这些分支未从 php.net 获得任何版本；参见较旧的 PHP 分支。 |
| 上传进度 | 是否在关键位置设置了 session.upload_progress.enabled=0（CVE-2026-115560 的缓解措施）：PHP-FPM 自身的视图（php-fpm -i）、每个可读的 php.ini、conf.d、FPM 池和 Apache 配置。站点级别的 .user.ini 和 .htaccess 会被报告但不计入，因为 php.net 表示它们对此设置无效。 |
| 核心完整性 | 针对 wordpress.org 运行 wp core verify-checksums |
| 插件完整性 | wp plugin verify-checksums --all，并列出无法验证的高级/自定义插件 |
| 上传目录 | wp-content/uploads 下任何可执行的 PHP 文件（忽略“Silence is golden”占位文件） |
| 近期更改 | 自窗口开始（默认 2026-10-17）以来修改的 PHP 和配置文件。WordPress 翻译包（wp-content/languages/**/*.l10n.php）在通过严格形状测试后单独计数；未通过测试的会被标记。 |
| 前置钩子 | .user.ini、.htaccess、php.ini 中的 auto_prepend_file / auto_append_file |
| Must-use 插件 | wp-content/mu-plugins 的内容（每次请求都会运行，在常规插件列表中隐藏） |
| 代码模式 | wp-content 中的经典 Web Shell 特征（eval(base64_decode(...))、$_POST[...]() 等） |
| 用户 | 所有管理员，以及在窗口内注册的任何账户 |
| 数据库 | siteurl/home、包含注入脚本或混淆代码的选项和文章 |
| Cron | WP-Cron 计划事件 |
| 日志 | 访问日志：窗口内每天的 5xx 响应数与窗口前最多 7 天的基线对比，以及窗口内返回 5xx 的 URL。错误日志和 PHP-FPM 日志：工作进程崩溃（段错误/总线错误）。 |
| 服务器 | 站点用户的 crontab 和 SSH authorized_keys |
| Docker | 每个运行着 php 二进制的容器：其中的 PHP 版本，以及容器是否仍在运行比磁盘上的镜像更旧的构建（已拉取但未重新创建） |
WP-CLI 以 --skip-plugins --skip-themes 运行，因此被植入后门的插件或主题在检查运行期间无法执行。
在每台被检查的机器上：
bash 3.2+、find、grep 和 sort -V（Linux 主机上的标准工具；在标准的 macOS 工作站上也可用）php，用于版本检查对于远程站点：从运行脚本的机器上具有 SSH 密钥访问权限。 脚本通过 SSH 在远程主机上自行运行；除上述要求外，远程主机上无需安装任何东西。
curl -O https://raw.githubusercontent.com/brentmartinmiller/php2shell-check/main/php2shell-check.sh
chmod +x php2shell-check.sh
# One site
./php2shell-check.sh /var/www/example.com
less php2shell-reports/*.md
# Every site on the box
printf '%s\n' /var/www/*/public_html > sites.txt
./php2shell-check.sh sites.txt
cat php2shell-reports/SUMMARY.md
尽可能以拥有站点文件的用户身份运行它。它也可以以 root 身份运行（WP-CLI 会获得 --allow-root），但此时 crontab 和 SSH 密钥检查会检查 root 的配置，而不是 Web 用户的配置。
git clone https://github.com/brentmartinmiller/php2shell-check.git
cd php2shell-check
cp sites.txt.example sites.txt # edit: one site per line
./php2shell-check.sh sites.txt
对于每个 user@host:path 条目，脚本会通过 SSH 登录，在那里运行自身，并将报告带回你机器上的 php2shell-reports/。远程主机上不会安装任何东西。SSH 以 BatchMode=yes 运行，因此需要无需密码提示即可工作的基于密钥的访问。
大多数共享主机（Hostinger、SiteGround、Bluehost 等）提供 SSH，但通常路径中没有 wp。用 which wp 检查。如果缺失，请将 WP-CLI 下载一次到你的主目录，并让脚本指向它：
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
WP="php $HOME/wp-cli.phar" ./php2shell-check.sh domains/example.com/public_html
没有 WP-CLI 时，文件系统检查仍会运行，报告会注明哪些内容被跳过。无论哪种方式，都要直接向主机方询问他们何时推出了修补后的 PHP，因为这是账户级检查无法看到的一点。
sites.txt 每行一个站点，可以是本地路径或 user@host:path。相对远程路径相对于 SSH 用户的主目录。以 # 开头的行会被忽略。参见 sites.txt.example。该文件位于 .gitignore 中，因此客户主机名不会进入提交。
非标准 SSH 端口、密钥和跳板主机应放在 ~/.ssh/config 中：
Host client-a
HostName 203.0.113.10
Port 2222
User deploy
IdentityFile ~/.ssh/client-a
然后将该站点列为 client-a:/var/www/html。
在 Docker 主机上运行 php -v 无法告诉你任何关于容器的信息，而拉取一个固定镜像也不会修补任何东西，除非从该镜像重新创建容器。某团队的站点在拉取后仍在 8.3.35 上停留了三天，原因正是如此。
当脚本在 docker ps 可用的主机上运行时，报告会得到一个 Docker 容器 部分，列出每个具有 php 二进制的运行中容器、其中的 PHP 版本，以及该容器是否已过期（其镜像的较新构建已在磁盘上，但容器从未被重新创建）。使用 docker compose up -d 重新创建，或者停止、删除并再次运行该容器。
要在容器内运行完整检查，请将其列为目标：
docker:wordpress-php-1:/var/www/html
脚本通过管道传入 docker exec 并在其中运行；容器内不会安装任何东西。它需要容器内存在 bash。官方的 php:* 和 wordpress:* Debian 基础镜像自带 bash；Alpine 基础镜像（-alpine）则没有，因此要么先执行 docker exec NAME apk add bash，要么退而求其次使用 docker exec NAME php -v。数据库通常位于单独的容器中，因此除非 PHP 容器能够访问它，否则会跳过用户、选项和 cron 检查。
将这些设置为环境变量：
| 变量 | 默认值 | 含义 |
|---|---|---|
SINCE | 2026-10-17 | “最近修改”和“最近注册”检查的时间窗口起点。这是首次确认的利用尝试，而非首次攻击；对于重要的站点，请将其设置得更早 |
WP | wp | 目标上的 WP-CLI 命令，例如共享主机上使用 WP="php $HOME/wp-cli.phar" |
LOGS | 自动 | 以空格分隔的访问日志、错误日志和 PHP-FPM 日志的路径或通配符，用于扫描，例如 LOGS="/var/log/nginx/*.log* /var/log/php8.3-fpm.log*"。默认情况下，脚本会在站点旁边（../logs）、~/logs、~/access-logs 和 ~/domains/*/logs 中查找，然后在 /var/log 下查找。轮转的 .gz 文件也会被读取 |
OUT | ./php2shell-reports | 报告写入的位置 |
WP="php $HOME/wp-cli.phar" SINCE=2026-10-15 ./php2shell-check.sh sites.txt
php2shell-reports/SUMMARY.md 是一个表格，每个站点一行：
| 站点 | CLI PHP | 上传进度 | ⚠️ 问题 | 🔎 复核 | 报告 |
|---|---|---|---|---|---|
| client-a:/var/www/html | 8.3.36 | off | 0 | 2 | client-a_var_www_html.md |
当在服务器层面确认 session.upload_progress.enabled=0 时，上传进度 为 off；未确认时为 on；无法读取任何 PHP 配置时为 ?。
每个站点的报告是一个 Markdown 文件，每项检查对应一个章节，使用以下标记：
先处理 ⚠️ 项，再逐项处理 🔎。
尝试不等于入侵。 互联网上几乎每个 PHP 站点此刻都在被扫描。访问日志中的利用尝试只说明站点被盯上了，并不说明它已被攻陷。文件和数据库检查才能告诉你真相。
5xx 突发是日志中最好的单一信号。 这些是内存破坏漏洞，因此失败或不完整的尝试往往会导致 PHP worker 崩溃，访客访问任何 URL 都会收到 500 或 502。有一个团队检查了整个时间窗口的代理日志，发现零个 5xx，称这是他们看到的最令人安心的结果。在繁忙的站点上，你需要窗口之前的基线，否则正常错误会淹没信号——这就是报告在窗口之外还显示 SINCE 之前最多七天的原因。同一 URL 上稳定的少量错误是插件损坏；分散在随机 URL 上的突发值得仔细查看，并结合 PHP-FPM 日志中的段错误行。
校验和胜过时间戳。 攻击者可以把文件的修改时间设为任意值。干净的“最近修改”列表令人安心；干净的 verify-checksums 结果是证据。这一点在这里比平时更重要：10 月 17 日利用此漏洞的人有四个安静的日子无人察觉，这足够回填文件时间并删减日志。
有些命中是正常的。
auto_prepend_file 指向 wordfence-waf.php 是 Wordfence，不是恶意软件。<script src=...>。wp-content/languages/**/*.l10n.php），这过去会在该列表中产生数十个命中。现在它们被单独计数，但仅当文件与 WordPress 写入的完全一致时：<?php 后跟一个 return [...] 语句，其非字符串内容只有括号、箭头、逗号和整数键。该名称下的任何其他内容都会被标记。.user.ini 或 .htaccess 中的 session.upload_progress.enabled=0 会被报告但不计入。php.net 表示 .user.ini 解析太晚无济于事，ini_set() 也不行；必须使用 php.ini、FPM 池（php_admin_flag[session.upload_progress.enabled] = off）或 Apache 自身配置，然后重启。wp-includes/php-ai-client/ 中留下重复文件，其名称被截断到固定长度（没有 .php 扩展名）。它们显示为“文件不应存在”，与全名孪生文件字节完全相同，且无法被 Web 服务器执行。用 md5sum 比较几个，如果愿意可以删除它们。wp-cli.phar 或其他工具也会被报告为额外文件。这不是攻击，但它不应可通过 Web 访问；将其移出文档根目录。CLI PHP ≠ Web PHP。 版本检查读取的是命令行 PHP。PHP-FPM 或 mod_php 可能运行着不同的版本。请通过 phpinfo() 或你的主机控制面板进行确认。发行版软件包（Debian、Ubuntu、RHEL）也可能在不更改版本号的情况下向后移植修复补丁；请查看软件包变更日志中的 CVE ID。在 Docker 主机上，CLI 版本完全无关紧要；参见 Docker。
第三个漏洞并未被十月发布的版本修复。 运行 8.3.36 的主机在版本检查中显示 ✅，但在 CVE-2026-115560 上仍显示 🔎，直到设置 session.upload_progress.enabled=0 或安装十一月发布的版本为止。php.net 认为该攻击向量不太可能：它需要应用代码将 session.serialize_handler 设置为 php_binary 或 php_serialize，然后在 session_start() 之前于运行时将其切换回 php。WordPress 核心根本不使用 PHP 会话，因此对于这些站点而言，这属于日常维护，而非遭到入侵的迹象。
php.net 仅为受支持的分支（8.2 至 8.5）发布了修复版本。脚本会将任何更旧的版本标记为可能存在问题，因为它没有可供比较的版本号，但实际情况各不相同：
7.4、8.0 和 8.1 已停止维护（EOL），但 PHP 安全团队发布了该修复的有限源代码向后移植，常见的第三方软件包仓库也已收录：Debian 和 Ubuntu 的 deb.sury.org、RHEL、Fedora 及其衍生版的 Remi 仓库，以及 AlmaLinux 和其他企业发行版的更新。运行这些分支之一的主机可能已在版本号不变的情况下完成修补。请通过软件包变更日志而非 php -v 进行验证，例如在 Debian 或 Ubuntu 上：
zgrep CVE-2026-109618 /usr/share/doc/php8.1-common/changelog.Debian.gz