漏洞修复版发布次日就有公开利用代码，官网在补丁日先关哪扇门
漏洞修复版发布次日就有公开利用代码，官网在补丁日要先关的是「可被远程触发的入口」，而不是把所有功能一起停掉。以 WordPress 的这轮问题为例：两枚免认证 SQL 注入漏洞 CVE-2026-63030 与 CVE-2026-60137 影响 WordPress 6.9.0-6.9.4 与 7.0.0-7.0.1，2026 年 7 月 17 日（周五）放出三个紧急修复版本，6.8.6、6.9.5、7.0.2 之后的版本已修复；公开验证代码在次日（周六）凌晨约 01:00 就开始流传。从「补丁可用」到「脚本可用」只隔了一天，这就是补丁日的现实。
时间线里最容易被忽略的一天
站点管理者通常盯两个时间点：漏洞公开的时间、补丁发布的时间。真正决定风险曲线的是第三个点：公开的可用利用代码出现的时间。
修复版本发布时，版本号、变更内容与受影响范围都是明牌，攻击者只需把差异还原成触发条件。公开利用代码出现后，攻击的技术门槛从「会挖漏洞」降到「会跑脚本」，未升级站点开始被批量扫描命中。上面的案例里，这个间隔是不到一天，而扫描与批量利用通常比人工验证更快扩散。
所以「我们还没收到攻击」不能作为拖延升级的依据：批量利用的探测行为往往先于业务异常出现，等异常可见时，入口已经被试过。
没打上补丁时先关什么
顺序按「能否被未认证请求触发」来排。
| 优先级 | 收敛动作 | 为什么有效 | 副作用 |
|---|---|---|---|
| 先关 | 未认证的公开写接口、批量查询与排序类参数入口 | 免认证注入的触发面就是这类入口 | 个别公开功能暂不可用 |
| 再关 | 后台登录面的可达范围，限制来源、开启验证码防护 | 阻断凭据撞库与登录后操作链 | 运维需走指定入口 |
| 同步做 | 停用非必要的扩展与主题，删掉不再使用的站点实例 | 缩小可被组合利用的组件面 | 需事后复核依赖 |
| 必做 | 完整备份并验证可恢复 | 一旦失陷可回退，避免升级与恢复互相阻塞 | 占用窗口时间 |
WordPress 这两枚漏洞的关键在「免认证」：触发不需要登录，靠的是请求参数进入数据库查询。对内容管理系统来说，值得优先排查的入口高度雷同：列表页的排序与筛选参数、搜索接口、表单提交、导入接口，以及带查询参数的归档类地址。
reCAPTCHA 验证码这类表单防护不能挡住注入，但能挡住凭据爆破与自动化提交，属于同一天的并行动作，不要把它当成主防。
补丁日当天的正确顺序
先验证备份再动生产。升级失败与利用造成的数据异常混在一起时，能区分二者的只有可用备份。
再按受影响范围判断优先级。多站点部署要逐个确认实例版本，不要假设主站升级了其他站点也随之安全。
升级后立即做三件事：确认版本号确实变化；抽查列表、搜索、表单与后台登录；把访问日志里升级前的可疑请求标记出来，为后续排查留证据。
最后处理凭据。升级只修复代码路径，已被窃取或猜测出的凭据不会因升级失效。AnQiCMS v3.6.6（2026-10-08）的升级建议里就包含这类动作：该版本修复了列表排序参数注入与站点切换登录凭证可被伪造两项高危问题，升级后要求轮换站点签名密钥并修改管理员密码。修完代码不轮换密钥，等于门换了锁、钥匙还留在外面。
长期把注入面收敛在系统设计里
补丁日的被动来自架构选择。三条长期做法能降低未来的应急次数：
一是减少运行期拼装查询。参数化查询与白名单字段校验能挡住绝大多数注入面，AnQiCMS 在 README 的安防描述里把防御 SQL 注入与 XSS 与内置 JWT 认证、内容敏感词过滤、防采集干扰码一起列为内置能力，属于系统层收口而不是插件叠加。
二是减少第三方面。免认证注入常出现在扩展与主题里，扩展越多，你依赖的补丁响应链越长。
三是把高危操作按域默认关闭。全站级操作（备份、升级、多站点管理）默认不对外暴露，需要时显式开启，能避免一次入口被突破后直接走到全站级动作。
常见问题
能不能只关后台不关公开接口？ 不行。免认证漏洞的触发点本来就不需要后台，关后台对这类漏洞几乎没有减害作用。
没来的及升级，WAF 规则够不够？ 可以争取时间，但不能替代升级。公开利用代码扩散后，规则绕过出现得很快，WAF 应作为缓冲而非结论。
如何判断是否已被利用？ 看升级前的访问日志里是否有针对排序/搜索参数的异常长请求、数据库错误页面、后台出现未知账号或权限变更、静态文件出现陌生文件。发现异常先保全证据再做清理。