WordPress站点遭SQL注入被下架，请求安全清理及恢复方案

先分析检测到的恶意SQL查询 #

你收到的两条查询是盲注探测语句，核心逻辑是通过sleep(5)的延迟来判断数据库中是否存在用户相关表（0x255f7573657273是十六进制编码的%_users），最终目标是抓取最高权限（meta_value=10）的管理员账号信息。这类语句是攻击的探测行为，不一定意味着数据库已经被写入恶意数据，但主机商下架站点是因为检测到了可被利用的漏洞代码。

核心问题：仅清理数据库无法彻底解决问题 #

不能只靠清理数据库来安全恢复站点，原因如下：

• 注入漏洞的根源几乎都在网站文件层：哪怕你之前保持WP核心、主题、插件为最新版，攻击成功后可能已经在服务器上植入了webshell、篡改了主题/插件文件，主机商检测到的"可利用代码"就是这些恶意文件，而非数据库中的记录。
• 数据库清理无法定位所有潜在风险：即使数据库被篡改，你很难排查出所有隐藏的恶意字段或记录；但更关键的是，只要文件中的漏洞或恶意代码还存在，攻击会持续发生。

当前主机商锁权限情况下的应急操作 #

1. 优先索要关键资源
   • 要求主机商提供数据库备份下载权限，或直接导出最近的干净备份文件给你。
   • 让主机商给出具体的恶意文件路径：他们能检测到注入行为，必然有对应的文件线索（比如接收恶意参数的脚本）。
2. 数据库安全检查（仅作为临时措施）
   • 登录数据库管理工具（如果还能访问），检查wp_users表：删除陌生的管理员账号，修改现有管理员的强密码（包含大小写、数字、特殊字符）。
   • 检查wp_usermeta表：删除非WP默认、非主题/插件生成的可疑meta_key字段。
   • 检查wp_posts/wp_postmeta表：删除包含webshell代码、垃圾内容的可疑文章或自定义字段。
   • 检查wp_options表：确认siteurl、home等核心配置未被篡改，删除陌生的自定义选项。

后续迁移托管WordPress主机的注意事项 #

• 搭建干净环境：先在新主机上安装全新的WP核心、官方原版主题和插件，不要直接迁移旧站点的文件（除非你能彻底排查干净）。
• 导入安全数据：将之前清理后的数据库备份导入新环境，再次检查用户、权限、内容的安全性。
• 开启安全防护：启用托管主机自带的WAF（Web应用防火墙）、恶意扫描、自动更新功能，给管理员账号开启两步验证，定期自动备份站点。

内容的提问来源于stack exchange，提问作者Niels Reynolds