php2shell
菜单

PHP2Shell 之后 WordPress 被入侵了？要检查这些

怀疑 WordPress 站点被入侵时的防御检查清单，包括入侵迹象、WP-CLI 检查、隔离止损、清理顺序，以及什么时候该请专业的应急响应公司。

先读这一段

Cloudflare、watchTowr 和 Patchstack 等厂商报告了针对 PHP2Shell 漏洞的攻击尝试。CISA、BSI 和 CERT-EU 还没有确认漏洞被利用，截至 10 月 21 日，它也不在 CISA 的已知被利用漏洞（KEV）目录里。所以你的站点有可能被入侵，但没有证据表明已经发生。这一页帮你去查。

针对有漏洞的 PHP 的攻击，可能发生在 WordPress 代码运行之前，所以 WordPress 和 PHP 的日志里可能什么都看不到。按下面的项目逐一检查，同时记住一条规则。

没查出问题，不代表站点是干净的

这里的每一项检查都可能漏掉东西。校验和工具只认识来自 wordpress.org 的文件。拿到足够权限的攻击者可以改日志、藏文件，或者把后门放进数据库。如果什么都没查到，你却仍有理由怀疑，就把站点当作已被入侵来处理，直到专业人员给出不同结论。

如果还没有给 PHP 打补丁，先做这件事，或者和检查同时进行。站点还跑在有漏洞的 PHP 上，清理完也只会等来下一次入侵。参见 检查 PHP 版本 和 切换 PHP 版本。

入侵迹象

账户

  • 你不认识的管理员账户，或者在 10 月 21 日当天及之后创建的账户。
  • 不是你创建的应用程序密码。在仪表盘中进入 用户 > 个人资料，向下滚动到 应用程序密码。脚本可以用它登录 REST API 而不需要你的密码，改了登录密码之后它依然有效。
  • 现有管理员账户的电子邮件地址被改过。
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp user application-password list <user-id>

第二条命令要对每个用户都运行一遍，不只是管理员。

核心文件和插件文件

wp core verify-checksums --include-root
wp plugin verify-checksums --all

第一条命令把核心文件和官方校验和做比对。加上 --include-root 后，它还会提示站点根目录里不属于 WordPress 的文件。第二条对插件做同样的检查，但只适用于托管在 wordpress.org 上的插件。付费插件和自定义插件没法这样验证，要拿它们和从开发者那里重新下载的版本对比。

校验失败的文件是一条需要追下去的线索。有些主机商和缓存工具会有意添加文件，所以下结论之前要逐个看。

不该出现 PHP 文件的地方

上传目录里应该只有图片、文档和媒体文件，不应该有 PHP。

find wp-content/uploads -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' \)
find . -type f -name '*.php' -mtime -7 -not -path './wp-content/cache/*'

第二条命令列出最近七天内改动过的 PHP 文件。更新也会产生结果，所以要留意你没想到的路径和文件名。

不是你装的插件

ls -la wp-content/mu-plugins wp-content/object-cache.php wp-content/advanced-cache.php wp-content/db.php

mu-plugins 里的必用插件每次请求都会加载，而且不会出现在普通的插件列表里。很多站点根本没有这类插件。另外三个文件是 drop-in。如果你没用对象缓存、页面缓存或自定义数据库层，就不应该有它们。

计划任务

wp cron event list

找出对应不上你所用插件的钩子、名字古怪的事件，以及每分钟都运行的事件。

PHP 和服务器配置

攻击者喜欢那些不动 WordPress 文件、却能在每次请求时执行代码的设置。

find . -name .htaccess -o -name .user.ini | xargs ls -la
grep -rn 'auto_prepend_file\|auto_append_file' . --include=.htaccess --include=.user.ini

如果出现不是你加的 auto_prepend_file 或 auto_append_file 行，这是危险信号。主机控制面板的 PHP 设置里也能设这个值，所以那里也要查。

其他迹象

  • 访客反映被跳转、看到广告，或者看到你没发布过的页面。
  • 搜索结果里出现挂在你域名下的垃圾页面。
  • 主机商发来滥用通知，或者暂停了站点。
  • 你的邮件服务器在发你没发起的群发邮件。
  • CPU、带宽或出站连接出现无法解释的峰值。

发现问题之后怎么做

按顺序来。

  1. 隔离。 把站点切到维护模式，或者在主机或 DNS 层面让它下线。如果站点处理付款或个人数据，要当作紧急情况处理。

  2. 保留证据。 删除任何东西之前，把整个站点（文件和数据库）以及服务器日志复制到服务器以外的地方。不要改动这份副本。应急响应公司、保险公司或数据保护机构可能会要。

  3. 给 PHP 打补丁。 换到已修复的构建，8.5.12、8.4.27、8.3.36 或 8.2.35，或者更新的版本。我们推荐 PHP 8.4。

  4. 更换所有凭据。 修改所有 WordPress 用户、数据库用户（以及 wp-config.php 里的 DB_PASSWORD）、主机控制面板、SFTP 和 SSH 账户的密码，还有站点里保存的所有 API 密钥。要在你信任的设备上操作。

  5. 撤销应用程序密码。 删掉你解释不了的，或者全部删掉。

    wp user application-password delete <user-id> --all

  6. 更换密钥盐值。 这会让所有会话退出登录，包括攻击者的会话。

    wp config shuffle-salts

  7. 从干净的来源重新安装。 核心和插件要从 wordpress.org 或开发者那里重新获取，不要用旧备份里的文件。

    wp core download --force --skip-content
wp plugin install <plugin-slug> --force

    重新安装只替换文件。你的上传文件、mu-plugins、drop-in、.htaccess、数据库，以及你发现的可疑账户和 cron 事件都不会被动到，这些要手动删除。

  8. 谨慎恢复备份。 只有在入侵之前做的备份才是干净的，而你可能不知道入侵发生在什么时候。如果恢复了备份，要在它上面把所有检查重做一遍。

  9. 之后继续观察。 一天后和一周后各重新跑一遍检查。

什么时候请应急响应公司

符合下面任何一条，就请专业人员。

  • 你发现了后门、陌生的管理员账户或意料之外的 PHP 文件。
  • 站点处理付款、健康数据或其他个人数据。你可能有法定的数据泄露报告义务，各国规定不同。
  • 你在同一个账户或同一台服务器上运行多个站点。一次入侵可能波及其他站点。
  • 你没法确定站点最后一次干净是什么时候。
  • 检查都没查出东西，但还是有地方不对劲。

我们不做取证，目前也不推荐具体的公司。推荐 页面说明了挑选时要看什么。要求对方书面写明服务范围、交付什么，以及证据由谁保管。

想快速判断自己的情况，用 情况判断。要确认服务器实际运行的版本，用 版本检查。

最后审阅：2026年10月22日