不用登录就能触发的 SQL 注入，怎么一路走到整站接管
不用登录就能触发的 SQL 注入，危害等级和需要账号的注入完全不是一个量级：它把攻击门槛降到「能访问这个 URL」。WordPress 核心的这一组漏洞（CVE-2026-60137 与 CVE-2026-63030，影响 6.8 至 7.0.1，修在 2026 年 7 月 17 日发布的 7.0.2）之所以能从读取数据走到整站接管，是三段条件同时成立——公开入口能带参数、参数被拼进查询语句、写入位置可被执行。安全厂商对这两个漏洞的组合做了独立验证，结论是包含远程代码执行在内的整站接管。
免认证入口意味着什么
免认证的入口通常是列表页、搜索页、订阅表单、公开接口，它们为了被搜索引擎收录并保证可用性必须对访客开放，参数校验容易被当成次要事项。判断自己有没有这类面，最直接的办法是把后台「允许匿名访问」的功能列出来，再看每个功能接受哪些参数：排序字段、分页、关键词、分类标识、时间范围，都是常见注入位。
门槛低还带来另一个后果：利用是批量化的。公告发布后，扫描脚本会在几小时内开始全网比对版本特征，等站长看到新闻时，暴露面早已被点名。
从拼接到写文件的三段路径
| 阶段 | 攻击者得到什么 | 站点侧失守的位置 |
|---|---|---|
| 读取 | 表结构、账号哈希、配置项 | 查询语句被参数控制，可返回非预期数据 |
| 提权 | 后台会话或直接写入能力 | 读到的凭证可复用，或认证逻辑被绕过 |
| 落地 | 在服务端执行代码 | 可写目录未收紧，上传与模板编辑未限权 |
第一段只是查询问题，第三段已经是文件系统设计问题。三段之间靠「凭证可复用」和「目录可写」两座桥连起来，任一座拆掉，路径就断。
同类注入位为什么难防：排序与筛选参数
排序参数是典型的「看着无害」位置：它来自 URL，最终拼进 ORDER BY 子句。字符串比较类过滤容易漏掉数字与标识符拼接，白名单校验才是可验证的做法——把允许的排序字段列成集合，请求里的值不在集合内就退回默认字段，而不是尝试转义后放行。AnQiCMS 在 v3.6.6（2026-10-08）修的正是列表排序参数 SQL 注入这一位，同期修的还有站点切换登录凭证可被伪造的问题；升级建议里要求轮换站点签名密钥并修改管理员密码，让旧凭证失效。这两条组合针对的是同类路径：先控制查询，再复用凭证。
框架层的收敛同样重要。AnQiCMS 用 JWT 做认证，内置内容敏感词过滤与防采集干扰码，把 SQL 注入和 XSS 的常见输入输出问题挡在框架层，站长不需要为了基础防护再去装扩展。
补丁前后的自查动作
补丁前能做的按有效性排序：先收窄暴露面（关闭非必要的公开列表接口、给公开表单加 reCAPTCHA 验证码挡批量提交）；再收紧写入（模板编辑权限只留给必要账号，可写目录权限收回）；然后固定证据（备份数据库与静态文件、导出访问日志）。
这些动作都是减害，版本才是是否受影响的判断依据。补丁到手后按顺序走：先备份，再在测试位升级并验证关键路径，最后动生产。
回退与证据保留
事件处置里最容易丢的是时间线。动手前留三样：可恢复的备份点、包含参数样本的访问日志、当前版本与配置快照。AnQiCMS 的备份与恢复覆盖数据与静态文件，配置收紧或误操作之后有可回退的位置。全站级高危操作按域设置暴露范围，备份、升级、多站点这类能力默认关闭（DefaultOff），即使控制面凭证被复用，攻击者能走的动作也被限制在你显式开启的范围内。
常见问题
只读注入是不是不影响安全？ 只读阶段能拿到账号哈希与配置项，后续提权与写入都靠它，日志里看不到写操作不代表没被读过。
装了 Web 应用防火墙还需要升级版本吗？ 需要。防火墙能拦特征化请求，绕过成本低，是否受这个漏洞影响只由版本区间决定。
怎么确认排序参数这一位已经安全？ 用一个不在允许列表里的排序值请求列表页，看是否退回默认排序而不是报错或返回异常数据；升级到修复版本后再核对一次后台版本号。