本文只记录已经脱敏的调查结论，不包含服务器密码、数据库口令、Cookie、会话令牌、密码哈希、攻击载荷或可以直接复用的利用代码。

这次网站安全事件，最开始看起来只是“管理员密码被别人改了”。我早上醒来后重新设置了密码，以为事情已经结束，结果过了一段时间，密码又一次失效了。

那一刻我才意识到，问题可能不在密码本身。有人也许已经拿到了更高权限，或者网站里还留着一个没有被修复的入口。后来我停止网站运行，保留源码、数据库和日志，再把访问记录、MySQL 二进制日志、数据库遗留数据和文件快照放在一起比对，才还原出这次事件的大致经过。

先说结论

这次管理员密码被修改，调查结论不是“攻击者先破解了我的密码”，而是旧版 WordPress 被未登录漏洞链成功利用：

• 攻击者不需要知道原管理员密码，也不需要先进入后台。
• 通过 WordPress 旧版本中的 REST Batch 路由和数据库查询漏洞，攻击者可以向数据库写入未授权数据。
• 现场留下了多个未授权管理员账号、权限记录、密码修改记录和管理员会话生成记录。
• 原管理员账号的密码被直接改写，所以我第一次改回密码后，漏洞入口仍然存在，攻击者可以再次操作。
• 现有证据没有显示这几轮密码修改之后，攻击者成功上传插件、主题、PHP 文件或继续控制服务器操作系统。

另外，阿里云在更早时间发现过一个 WebShell 文件。这个文件已经被隔离在网站目录之外，但目前没有证据证明它就是 8 月密码修改事件的入口。时间线和日志更支持把它作为一次更早发现的独立安全事件来处理。

事情是怎样被发现的

2026 年 7 月 20 日：发现旧 WebShell 告警

阿里云安全中心发来“发现后门（Webshell）文件”的告警。文件位于 WordPress 的 wp-content 子目录中，检测标签是“任意 PHP 代码执行”。

我没有直接在原位置运行或打开它，而是先保留证据，再把它移出 Web 根目录进行隔离。后续扫描没有发现它仍在当前网站路径上可访问，也没有发现新的活动 WebShell。

这条告警非常重要，但它不能自动解释之后所有异常。安全事件调查中，看到一个恶意文件，并不代表它一定参与了后续每一次账号操作，仍然要结合时间、日志和数据库记录判断。

2026 年 7 月 29 日：第一次成功利用

访问日志中出现了一组针对 WordPress REST Batch 功能的异常请求，随后数据库里出现了一个不属于我的管理员账号。

这说明攻击者至少在那一天已经成功利用了网站漏洞。攻击者还尝试访问后台和插件相关功能，但现有记录没有证明插件或主题上传成功。

2026 年 8 月 5 日凌晨：第一次修改管理员密码

凌晨 0 点 22 分左右，日志中出现第一轮异常请求。几秒后，数据库记录显示：

• 新增了一个未授权管理员账号；
• 原管理员账号的密码被修改；
• 为原管理员账号生成了新的登录会话。

早上我从手机登录后把密码改了回来。这个动作暂时恢复了账号控制，但没有消除漏洞，所以只是把结果改回去，并没有堵住入口。

2026 年 8 月 5 日上午：第二次修改与停站

上午 10 点 14 分左右，类似的请求再次出现。数据库中又新增了一个未授权管理员账号，原管理员密码再次被改写，并再次生成了管理员会话。

这次我重新改回密码后，马上通过宝塔面板停止网站运行，避免攻击者继续利用在线入口。停止网站是当时最重要的动作之一：它给了我保全证据、检查文件和核对数据库的时间。

2026 年 8 月 11 日以后：取证、清理、升级与复检

在保留处置前快照后，我对源码、数据库、日志和服务器持久化项目进行了检查，随后清理未授权数据、升级 WordPress、轮换凭据并逐项恢复网站。

后续审计还发现，处置时升级到的 7.0.2 虽然已经修复了这次实际利用的旧漏洞链，但它仍不是之后的最新安全版本；后续应继续升级到 7.0.3 或更高的受支持版本。

攻击者是怎样改掉密码的

调查中最关键的证据来自三处：Nginx 访问日志、MySQL 二进制日志，以及数据库里留下的用户和权限记录。三者的时间能够互相对应。

这次利用针对的是 WordPress 6.9.4。攻击者通过公开的 REST Batch 路由，结合 WP_Query::author__not_in 查询处理中的漏洞，构造出未登录即可触发的数据库写入链。相关问题后来被记录为：

• CVE-2026-60137：查询参数处理导致的 SQL 注入问题；
• CVE-2026-63030：REST Batch 路由混淆问题。

两处缺陷组合后，攻击者能够让应用执行本来只有管理员才能完成的数据库操作。这里不展开具体请求格式和利用载荷，因为它们对正常站长没有帮助，却可能被直接滥用。

从结果看，攻击者完成了几件事：

1. 创建新的管理员账号，并写入对应的管理员权限；
2. 直接替换原管理员账号的密码哈希；
3. 为原管理员账号生成有效会话，让登录状态不只停留在数据库层面；
4. 留下用于验证利用是否成功的数据库记录。

所以我看到的“密码被改”，其实只是攻击链最后呈现出来的一个结果。它不是传统意义上的登录爆破，也不需要攻击者先拿到我的旧密码。

攻击者后来做了什么

这是我最关心的问题。通过日志、数据库和文件扫描交叉核对，目前能够确认的范围如下。

已确认发生的事情

• 多轮未登录漏洞利用请求；
• 创建多个未授权管理员账号；
• 修改原管理员密码；
• 生成管理员会话；
• 写入与漏洞验证有关的 changeset 和元数据记录。

没有找到证据证明的事情

在现有取证范围内，没有发现攻击者成功完成以下操作：

• 上传或启用插件、主题；
• 通过后台编辑器修改 PHP 文件；
• 在媒体上传目录写入 PHP 文件；
• 批量修改文章、站点设置或用户资料；
• 执行数据导入、导出或明显的数据窃取写入；
• 通过 SSH、root、计划任务、systemd、PHP 前置文件、Nginx Lua 或宝塔任务建立系统持久化。

最终扫描覆盖约 28,707 个服务器文件，WordPress 核心文件全部通过官方校验，自定义 PHP 文件语法检查也全部通过。扫描范围内没有发现当前生效的 WebShell。

这并不等于可以用静态扫描“数学证明服务器绝对干净”。自定义主题和插件没有完整、可信的官方基线，其中 xk-zhplugs 还包含受保护或混淆代码，因此我只能说：在保存下来的日志、数据库和文件范围内，没有找到更多已经被证实的恶意持久化。

源码审计又发现了什么

确认入侵入口之后，我又对活动主题和插件做了更深入的只读审计。这里要特别区分两类结论：下面的问题是“源码中确实存在的风险”，但没有证据证明它们就是本次密码修改使用的入口。

这些问题说明，网站安全并不只是“把某个木马文件删掉”。即使文件扫描没有发现后门，权限检查、CSRF、输出转义、SQL 参数化、订单归属和依赖版本中的缺陷，仍然可能成为下一次入侵的入口。

我做了哪些处理

这次处置大致分成四个阶段。

1. 先隔离，再取证

我先停止网站运行，保留源码、数据库、配置、日志和文件哈希快照。没有一开始就直接删除所有异常文件，因为删除虽然能让告警消失，却可能同时破坏还原攻击过程所需的证据。

2. 清理数据库中的未授权内容

清除了调查确认的未授权管理员账号、权限元数据、恶意 changeset、关联 postmeta、全部旧会话和应用密码，只保留自己的管理员账号。

3. 升级并轮换凭据

WordPress 先升级到 7.0.2，完成数据库结构升级；同时轮换 WordPress salts 和专用数据库账号密码，关闭后台文件编辑功能，并收紧 wp-config.php 权限。

后续复核发现 7.0.2 仍应继续升级到 7.0.3 或更高的受支持版本，这一步不能因为网站已经恢复就省略。

4. 收紧 Web 层和文件层

我把公开目录中的配置备份和安装元数据移出 Web 根目录，并增加 Nginx 拒绝规则；对 REST Batch 路由、上传目录中的 PHP 文件、常见配置备份和高风险请求增加拦截；同时检查上传目录、计划任务、系统服务、PHP 配置和宝塔任务。

网站没有直接从公网恢复，而是先在受限环境中验证首页、文章、登录页、后台、插件页和个人资料页，确认没有新增 PHP 严重错误后再恢复访问。

为什么没有查到攻击者的真实身份

日志里看到的来源地址并不是攻击者的真实公网 IP。我的域名使用了腾讯云 EdgeOne，源站记录到的是代理节点地址，而且当时没有正确配置真实客户端 IP 的还原。

因此，仅凭服务器日志不能可靠判断攻击者是谁，也不能把代理节点地址直接归属到某个个人。若要继续追查，只能向云厂商申请保全对应时间段的边缘访问日志，再结合合规流程进行分析。对普通站长来说，更现实的目标是先完成隔离、修复和证据保存，不要把代理节点误当成攻击者身份。

这次事件给我的教训

密码被改，不代表密码泄露

管理员密码异常当然要立即重置，但重置密码只能恢复控制权。如果攻击者利用的是未登录漏洞，入口仍然存在，密码很快还会再次被改掉。

“版本能用”不等于“版本安全”

WordPress 6.9.4 当时仍能正常运行页面，却已经处在可被利用的版本范围内。后来升级到 7.0.2 后，又发现它并不是最新安全版本。核心、主题和插件都需要持续跟进安全更新，不能只看网站还能不能打开。

备份应该能帮助恢复，也应该能帮助调查

如果没有处置前的源码、数据库、日志和哈希快照，很难判断哪些内容是攻击者写入的，哪些只是网站正常变化。备份不是只在网站坏了以后拿来恢复，它也是事故调查的时间坐标。

防护需要分层

核心升级、最小权限、Nonce、输出转义、SQL 参数化、上传目录禁止执行 PHP、Nginx 规则、登录限速、MFA、文件完整性监控和异地日志，这些措施单独看都不神奇，但组合起来才能降低一次漏洞成功后的影响范围。

不可审计的代码要谨慎使用

混淆或加密代码不一定就是木马，但它会让维护者无法确认里面到底做了什么。对于长期运行的网站，能审计、能校验、能追踪版本，比“功能很多”更重要。

给站长的一份事后检查清单

• 立即停止受影响站点，先保存证据，再清理；
• 升级 WordPress 核心、主题和插件到受支持的安全版本；
• 检查管理员列表、权限元数据、应用密码和全部登录会话；
• 轮换管理员、数据库、宝塔、云平台、邮件和对象存储凭据；
• 关闭后台文件编辑，禁止上传目录执行 PHP；
• 将配置备份、安装文件和日志移出 Web 根目录；
• 对登录、密码修改、用户创建和文件变化建立告警；
• 保留 Nginx、PHP、WordPress、SSH、宝塔和数据库日志，并尽量异地保存；
• 对自定义主题和插件建立可信版本与哈希基线；
• 正确配置反向代理的真实客户端 IP，方便后续追踪和封禁。

结语

这次经历让我重新理解了“网站被入侵”这几个字。它不一定从一个明显的木马开始，也不一定表现为首页被篡改。有时候，最先看到的只是一个密码修改通知；真正的入口可能藏在一个看起来普通的版本、一个没有权限校验的接口，或者一条很久没有人关注的旧代码路径里。

好在日志、数据库和源码快照最终把这条链路拼了出来：密码被修改的原因被确认，未授权账号被清理，站点文件和核心校验通过，旧 WebShell 也被隔离。接下来要做的，不只是让网站重新打开，而是把版本、权限、日志和备份都纳入日常维护。

网站恢复运行只是事故处理的终点，也是下一轮安全维护的起点。