XML-RPC 是 WordPress 自 3.5 版本起默认开启的远程接口，入口文件为站点根目录的 xmlrpc.php。它最初用于支持桌面博客客户端、移动 App 和跨站发布（Pingback/Trackback）等远程调用场景。问题在于：大多数现代站点早已不再依赖这些功能，但接口仍然对外开放，于是形成了一块无人使用却持续暴露的攻击面。治理这块暴露面的核心不是"一刀切关闭"，而是先确认它是否还在被依赖，再按风险与依赖关系选择最小化、可验证、可回滚的处置方式。
为什么 XML-RPC 的暴露值得单独治理
XML-RPC 的风险对象是一个无需多次交互、就能被远程脚本批量调用的认证入口。它带来的主要业务影响集中在三类。
一是口令爆破的放大效应。普通 WordPress 登录每次请求只能尝试一组账号密码，而 XML-RPC 的 system.multicall 方法允许在单个 HTTP 请求里打包大量方法调用。攻击者可以把成百上千组口令尝试塞进一次请求，用极少的请求数完成大规模撞库，这会让仅针对登录页的频率限制形同虚设。
二是 Pingback 相关的服务端请求与反射放大。pingback.ping 方法会让你的站点主动向指定 URL 发起请求，历史上被用于探测内网、代理攻击流量以及参与分布式拒绝服务（DDoS）反射。即便站点本身没有被攻破，也可能成为攻击他人的跳板。
三是无谓的资源消耗与噪声。即使所有调用最终都认证失败，持续的爆破请求也会占用 PHP 进程、数据库连接和带宽，推高服务器负载，并在日志中淹没真正值得关注的异常。
需要说明的是，参考资料中出现的近期 WordPress Core 高危漏洞（如 CVE-2026-60137、CVE-2026-63030）主要涉及 REST API 的 /batch/v1 批量请求路由处理缺陷，与 XML-RPC 并非同一入口。但它们指向同一条治理原则：任何默认开启、支持批量操作的远程接口都应被纳入暴露面盘点，而不是默认信任。请以官方公告和漏洞数据库的受影响版本为准来评估自身是否受影响。
第一步：盘点依赖与访问日志，而不是直接关闭
在动手限制之前，先回答一个问题——这个站点到底有没有在真正使用 XML-RPC。贸然关闭可能影响移动 App 发布、Jetpack 的部分功能，或某些依赖远程发布的第三方集成。
确认接口当前是否对外开放
最直接的方式是观察 xmlrpc.php 对 GET 请求的响应。接口开启时，访问该路径通常返回类似"XML-RPC server accepts POST requests only"的提示并带有 405 状态；若返回 403 或 404，往往说明已被某种规则拦截或禁用。你也可以在授权范围内，对自己的站点发送一次合法的 system.listMethods 调用，查看返回的方法列表，从中判断 pingback.ping、system.multicall 等高风险方法是否可用。这些验证都应在你拥有或已获授权的站点上进行。
从访问日志反推真实依赖
Web 服务器访问日志是判断依赖关系最可靠的依据。筛选最近一段时间（建议至少覆盖一个完整业务周期）内对 xmlrpc.php 的 POST 请求，重点看三件事：
- 请求来源 IP 是否集中在少数几个固定地址，这些往往是你自己的移动 App、监控或集成服务；
- 请求是否大量来自分散的陌生 IP、User-Agent 高度雷同，这通常是爆破特征；
- 请求体中调用的方法名，
wp.getUsersBlogs配合system.multicall大量出现基本可判定为撞库尝试。
以 Nginx 为例，可以用如下命令快速提取相关请求做初步统计：
grep 'xmlrpc.php' /var/log/nginx/access.log
| awk '{print $1}'
| sort | uniq -c | sort -rn | head -20如果日志显示除了爆破流量外几乎没有正常来源，说明关闭接口的业务风险很低；如果存在稳定的合法来源，则更适合"按来源限制"而非直接停用。
第二步：按适用条件选择处置方式
盘点清楚后，再从三种处置方式中选择，而不是一上来就用最激进的方案。三者的适用条件不同，可以组合使用。
| 处置方式 | 适用条件 | 优点 | 代价与注意 |
|---|---|---|---|
| 按来源限制访问 | 有少量固定、可信的调用来源（如自建 App、集成服务） | 保留功能的同时收窄暴露面 | 来源 IP 变动需维护白名单 |
| Web 服务器层拦截 | 完全不需要 XML-RPC，希望在应用之前挡掉请求 | 请求不进入 PHP，省资源、挡爆破 | 配置错误可能误伤，需测试 |
| 应用层停用接口 | 不需要功能，或作为纵深防御补充 | 跨服务器环境通用，随站点迁移 | 仍会进入 PHP 处理一次 |
方式一：按来源限制访问
当你确认只有固定来源需要调用时，优先用白名单放行、默认拒绝。以 Nginx 为例：
location = /xmlrpc.php {
allow 203.0.113.10; # 你的可信来源，示例地址请替换
deny all;
}Apache（启用 .htaccess 的环境）可以用：
<Files xmlrpc.php>
Require ip 203.0.113.10
</Files>这种方式保留了接口功能，同时把开放范围从"全网"收窄到"已知来源"，是对仍在使用移动 App 或集成的站点最平衡的选择。
方式二：在 Web 服务器层直接拦截
当确认完全不需要该接口时，在 Web 服务器层拦截能让恶意请求根本不进入 PHP，从而避免消耗应用资源。Nginx 可直接返回 403：
location = /xmlrpc.php {
deny all;
access_log off; # 可选，避免日志被爆破请求刷屏
}参考资料中也提到，在不需要第三方应用调用时，可在 Nginx 的 server block 中直接对 xmlrpc.php 返回 403。这种方式的优点是生效在应用之前，缺点是规则写错路径或作用范围时可能误伤，上线前务必在测试环境或低峰期验证。
方式三：在应用层停用接口
如果你没有 Web 服务器配置权限（例如共享主机），可以在应用层停用。最轻量的方式是在主题的 functions.php 或自定义插件中关闭：
add_filter( 'xmlrpc_enabled', '__return_false' );参考资料也提到可借助 Disable XML-RPC 一类插件达到同样效果，适合不便改代码的站长。需要注意的是，xmlrpc_enabled 过滤器关闭的是认证相关方法，请求仍会被 PHP 加载并处理一次；因此在条件允许时，应用层停用更适合与 Web 服务器层拦截配合，形成纵深防御。把过滤器写进独立的小插件而非主题文件，还能避免更换主题后配置丢失。
第三步：验证规则生效并安排功能回归
配置改完不等于治理完成，必须验证规则真正生效，并确认没有误伤正常业务。
验证限制规则是否生效
- 从非白名单网络访问
xmlrpc.php，确认返回预期的 403（拦截）或功能已关闭的响应； - 从白名单来源发起一次合法调用，确认仍能正常工作（仅适用于按来源限制的场景）；
- 复查 Web 服务器配置是否存在语法错误，Nginx 可用
nginx -t检查后再 reload，避免整站不可用； - 关闭接口后，再次观察访问日志，确认爆破请求已被挡在 PHP 之外，而不是仍在被处理。
安排功能回归，重点看三类依赖
停用或限制后，按清单逐项确认受影响功能：
- 移动端：用官方 WordPress App 或你使用的客户端尝试登录和发布，确认是否仍可用；
- 第三方集成：检查依赖远程发布或远程管理的服务（如部分发布工具、自动化流程）是否报错；
- 站内互联：如果你的内容生态依赖 Pingback/Trackback 通知，确认关闭后是否影响相关联动。
如果某项功能确实中断且业务需要，应回到"按来源限制"方案放行对应来源，而不是重新对全网开放。
第四步：持续监控与可回滚的变更安排
治理动作要像一次可控的变更来管理，而不是一次性操作。
变更前先备份相关配置文件（Web 服务器配置、functions.php 或插件状态），并记录改动内容与时间，确保出现问题时能在几分钟内回滚到已知良好状态。回滚方式应与处置方式对应：Web 服务器层改动通过还原配置并 reload 生效，应用层改动通过移除过滤器或停用插件生效。
变更后保留一段观察期，持续关注三类指标：xmlrpc.php 的请求量与状态码分布是否符合预期、服务器负载与 PHP 进程占用是否下降、业务侧有无用户或集成反馈异常。同时，把"任何默认开启的远程接口都纳入暴露面盘点"固化为常规安全运维动作——定期检查异常接口请求日志、保持 WordPress Core 与插件更新到安全版本、按最小权限收窄后台访问来源，才能让这次治理的收益长期保持。
就实践顺序而言，推荐的优先级是：先盘点依赖与日志，再对完全无用的接口在 Web 服务器层拦截并辅以应用层停用，对仍有合法来源的接口采用来源白名单，最后统一纳入监控与回滚机制。这样既最小化了暴露面，又把误伤业务和不可逆变更的风险控制在可接受范围内。
甘肃省 1F
先查日志再动配置，心里踏实些