How to Actually Protect Yourself From wp2shell (Not Just "Update WordPress")

查看原文 / View Original 编辑 / Edit

How to Actually Protect Yourself From wp2shell (Not Just “Update WordPress”)

如何真正防御 wp2shell 漏洞（不仅仅是“更新 WordPress”）

Everyone’s telling you the same thing right now: update WordPress. Which is, fine, yes, obviously but that’s not enough. Patching closes the hole. What if someone is already in your system? So let’s actually walk through this properly: what to do right now, what to do if you can’t patch immediately, and what to do if you think you were already hit. 现在每个人都在告诉你同一件事：更新 WordPress。这当然没错，也很显然，但这还不够。打补丁只是堵住了漏洞，但如果已经有人进入了你的系统呢？因此，让我们来详细梳理一下：现在该做什么、无法立即打补丁时该做什么，以及如果你认为自己已经中招了该怎么办。

S1: Stop assuming you’re patched. Go check.

S1：别再假设你已经打好补丁了，去检查一下。

WordPress flipped on forced automatic background updates for this one because of how serious it is. That’s great, except “forced” doesn’t mean “guaranteed”, VERIFY IT. Go look at your actual running version right now: 由于此漏洞极其严重，WordPress 开启了强制自动后台更新。这很好，但“强制”并不意味着“万无一失”，请务必核实。现在就去查看你实际运行的版本：

  • In the dashboard: wp-admin > Updates

  • Via WP-CLI, if you have shell access: wp core version

  • 在仪表盘中：wp-admin > Updates

  • 如果你有 Shell 访问权限，通过 WP-CLI 执行：wp core version

You want to see 7.0.2 if you’re on the 7.0 line, or 6.9.5 if you’re on 6.9. If you see anything else — 6.9.0 through 6.9.4, or 7.0.0/7.0.1 — you’re still exposed. Update it now!! Come back when done. 如果你处于 7.0 分支，你应该看到 7.0.2；如果你处于 6.9 分支，则应看到 6.9.5。如果看到其他版本（6.9.0 到 6.9.4，或 7.0.0/7.0.1），说明你仍处于风险中。立即更新！！完成后再回来。

A few situations where the forced update quietly doesn’t happen: 以下几种情况可能导致强制更新悄无声息地失败：

  • Managed hosting environments where the host controls the update pipeline and hasn’t pushed it yet.

  • Sites with a “disable auto-updates” plugin installed months ago for stability reasons and never revisited.

  • wp-config.php with WP_AUTO_UPDATE_CORE explicitly set to false.

  • Staging or dev environments nobody thinks of as “production” but that are still internet-facing.

  • 托管主机环境：主机商控制更新流程且尚未推送更新。

  • 安装了“禁用自动更新”插件的站点：为了稳定性安装后就没再管过。

  • wp-config.php 中明确将 WP_AUTO_UPDATE_CORE 设置为 false。

  • 暂存或开发环境：没人将其视为“生产环境”，但它们依然暴露在互联网上。

If any of that describes you, don’t wait on the automation. Update manually. 如果以上任何一条符合你的情况，不要等待自动更新，请手动更新。

S2: If you genuinely can’t update right now, here’s your stopgap

S2：如果你确实无法立即更新，这是你的临时补救措施

Maybe you’re facing a compatibility issue, a change freeze, or a custom plugin that isn’t ready yet. It happens. If you need a little more time before applying the real fix, here’s a workaround that helps: Block anonymous access to the batch REST endpoint. 也许你正面临兼容性问题、变更冻结，或者自定义插件尚未准备好。这种情况很常见。如果你在应用正式修复前需要更多时间，这里有一个有效的变通方法：阻止对批量 REST 端点的匿名访问。

The vulnerable surface is specifically /wp-json/batch/v1 and its query-string equivalent, ?rest_route=/batch/v1. You can handle this a couple of ways: 受影响的攻击面主要是 /wp-json/batch/v1 及其查询字符串等效形式 ?rest_route=/batch/v1。你可以通过以下几种方式处理：

  • At your WAF or reverse proxy (Cloudflare, Nginx, etc.) — block or challenge requests to those paths from unauthenticated traffic.

  • With a plugin that restricts REST API access to logged-in users only.

  • 在 WAF 或反向代理（Cloudflare、Nginx 等）层面：阻止或拦截来自未认证流量对这些路径的请求。

  • 使用插件：将 REST API 访问权限仅限于已登录用户。

I want to be upfront about the tradeoff here: both of these can break legitimate things. The block editor uses REST endpoints. So do a lot of mobile apps and third-party integrations. This is a temporary bandage, not a real fix — treat it that way and get back to updating properly as soon as you can. 我必须坦诚地说明权衡之处：这两种方法都可能破坏正常功能。区块编辑器（Block Editor）会使用 REST 端点，许多移动应用和第三方集成也是如此。这只是临时的创可贴，而非真正的修复方案——请务必以此心态对待，并尽快恢复到正常的更新流程。

If you’re behind Cloudflare, also check whether their managed ruleset for this specific vulnerability is switched on for your zone. They shipped detection rules pretty quickly after disclosure. 如果你在使用 Cloudflare，请检查针对此漏洞的托管规则集是否已为你开启。他们在漏洞披露后很快就发布了检测规则。

S3: Figure out if you were already hit

S3：确认你是否已经中招

This is the part almost everyone skips, and it’s the part that actually matters if your site was sitting in an affected version between when this became exploitable and when you patched. 这是几乎每个人都会忽略的部分，但如果你的站点在漏洞可被利用期间到你打补丁之前一直处于受影响版本，这才是真正重要的一步。

Quick gut check on timeline: disclosure was July 17. In-the-wild exploitation was confirmed within days of that. So if your site was running 6.9.0-6.9.4 or 7.0.0-7.0.1 and internet-facing anytime after that, don’t just assume nothing happened—please go look. 快速回顾时间线：漏洞于 7 月 17 日披露，几天内就确认了野外利用。因此，如果你的站点在此后的任何时间运行着 6.9.0-6.9.4 或 7.0.0-7.0.1 版本且暴露在互联网上，请不要假设什么都没发生，务必去检查一下。

Things worth checking: 值得检查的项目：

  • Admin accounts: Anything new that you didn’t create? Any password resets you didn’t trigger? This is usually the first thing an attacker does once they’ve got code execution — plant a persistent admin account.

  • File timestamps: Look through wp-content, especially theme and plugin directories, for files modified around dates that don’t line up with your activity. A stray .php file with a weird name in an upload directory is a classic sign.

  • Scheduled tasks: Check wp_cron for anything unfamiliar. Attackers sometimes use this for persistence.

  • Access logs: Search for anonymous POST requests hitting /wp-json/batch/v1 or ?rest_route=/batch/v1 around your exposure window. That’s the fingerprint of someone probing or exploiting the chain.

  • Database: If you’re comfortable, check wp_users and wp_options for anything off — unexpected serialized data, unrecognized options keys.

  • 管理员账户： 有没有你没创建的新账户？有没有你没触发的密码重置？这是攻击者获得代码执行权限后通常做的第一件事——植入一个持久化的管理员账户。

  • 文件时间戳： 检查 wp-content，特别是主题和插件目录，查看是否有修改日期与你的操作不符的文件。上传目录中出现名字奇怪的 .php 文件是典型的入侵迹象。

  • 计划任务： 检查 wp_cron 是否有不熟悉的任务。攻击者有时会利用它来实现持久化。

  • 访问日志： 搜索在你的暴露窗口期内，针对 /wp-json/batch/v1 或 ?rest_route=/batch/v1 的匿名 POST 请求。这是攻击者探测或利用漏洞的指纹。

  • 数据库： 如果你熟悉数据库操作，检查 wp_users 和 wp_options 是否有异常——例如意外的序列化数据或无法识别的选项键。

If you find something — anything — from that list, this stops being a “patch and move on” situation. At that point: 如果你在上述列表中发现了任何异常，这就不仅仅是“打个补丁就完事”的情况了。此时你需要：

  • Rotate every credential: WordPress admin passwords, database credentials, API keys, FTP/SSH.

  • Actually search for backdoors rather than just deleting one file — attackers rarely plant just one way back in.

  • If you have a clean backup from before the exposure window, restoring is usually faster and safer than manual cleaning.

  • If this is a business-critical site, loop in an incident response professional rather than doing forensics solo at 1am.

  • 轮换所有凭据：WordPress 管理员密码、数据库凭据、API 密钥、FTP/SSH 密码。

  • 彻底搜索后门，而不仅仅是删除一个文件——攻击者很少只留一个后门。

  • 如果你有漏洞暴露前的干净备份，恢复备份通常比手动清理更快、更安全。

  • 如果这是关键业务站点，请联系专业的应急响应人员，而不是在凌晨独自进行取证。

S4: The stuff that’s worth doing regardless of this specific bug

S4：无论此漏洞如何，都值得做的预防措施

None of this is wp2shell-specific, but it’s exactly the kind of thing that determines whether the next core vulnerability catches you exposed: 这些建议并非针对 wp2shell，但它们决定了你是否会在下一次核心漏洞爆发时处于裸奔状态：

  • Actually turn on auto-updates for core, and check periodically that it’s working.

  • Keep an eye on whether your host’s update pipeline is timely.

  • Don’t expose more REST API surface than you need; if you’re not using the batch endpoint, restrict it.

  • Have a “did this site get patched” checklist for moments like this, so you’re not scrambling to remember which of your fifteen WordPress installs is still on an old version.

  • 真正开启核心自动更新，并定期检查其是否正常工作。

  • 关注你的主机商更新流程是否及时。

  • 不要暴露不必要的 REST API 接口；如果你不需要批量端点，就将其限制。

  • 为类似时刻准备一份“站点是否已打补丁”的检查清单，这样你就不会在面对十几个 WordPress 站点时，手忙脚乱地去回忆哪一个还在运行旧版本。

← 返回新闻列表 / Back to news list