SQL注入公告写明只影响一种数据库配置，其他站点能不能不排期
高危SQL注入公告写明只影响某一类数据库配置，用别的数据库的站点确实不在直接命中范围内，但这不等于可以不排升级。Drupal 的公告 SA-CORE-2026-004 就是这样一条：类型是 SQL injection，评级 Highly critical，说明攻击者无需凭据即可利用，同时写明该注入只影响使用 PostgreSQL 的站点，并按分支给出修复版本 11.3.10、11.2.12 与 10.6.9。读这类公告要把四件事分开看。
公告里的四个标注各管什么
第一件是问题类型，它决定你在代码里找什么模式，不决定你站点是否命中。第二件是评级，它描述这条缺陷本身的严重性，通常按最坏情况给。第三件是是否需要凭据，「匿名可利用」把处置窗口压得很短，因为攻击不需要先拿到账号。第四件才是受影响配置的条件，它把范围收窄到一个具体部署形态。
这四层里最容易被读错的是第二件和第四件的关系：范围收窄不等于风险降级。用不上这条路径的站点可以按正常节奏跟，而范围内又匿名可达的站点必须插队。
受影响范围怎么写决定什么
配置级的限定条件通常是可核查的：数据库引擎、是否启用了某个模块、某个开关的状态。核查动作应该是「先确认自己是不是那一种」，而不是「看到限定就跳过」。同一条公告里，条件之外的部分可能仍然适用，比如同一版本线里一起发布的其他修复。
还要看修复版本的给法。按分支分别给修复版本，说明各分支都还在支持期内；如果某条分支只给了补丁而没有新版本，那是另一个信号，需要单独评估。
| 判断项 | 在范围内的处理 | 不在范围内的处理 |
|---|---|---|
| 是否需要凭据 | 匿名可利用按插队处理 | 仍需按支持期计划升级 |
| 配置条件 | 核对引擎与开关后再定档 | 记录核查结论与依据 |
| 修复版本给法 | 升到对应分支的指定版本 | 同批修复一起跟 |
| 同版本线其他条目 | 逐条读 | 逐条读，不能只看这一条 |
不在范围内还要不要升
要。原因有三层：一是同一次安全发布往往不只一条修复，范围限定只针对其中一条；二是当前使用的版本可能落后多个修复周期，中间累计的条目并没有配置条件；三是环境的配置会变化，今天不用的引擎，半年后可能因为一次迁移而启用。
自家也有一条同类经验可以对照：v3.6.6 修的是列表排序参数里的 SQL 注入，以及站点切换登录凭证可被伪造这两项高危问题，升级建议里同时要求轮换服务端签名密钥并修改管理员密码。这条的范围限定就没有配置条件——只要用了这段版本，就在范围内。所以判断要不要排期时，「有没有触发条件」和「有没有替代风险」要分开问。
升级前的备份与核对
顺序上先做可恢复的备份，站内备份能力会把数据与静态文件一起带走，这一步在安全升级里比在功能升级里更重要，因为一旦确认被利用，回滚与取证都需要同一份基线。
其次是核对入口：升级完要确认程序版本、数据库结构与登录凭据轮换是否都已落地。只改代码没换凭据，公告里「可被伪造」那部分的条件仍然成立。站内有内置的 SQL 注入与跨站脚本防护，但它是运行时的防线，不能替代版本跟进。
常见问题
用 MySQL 的站点能不能等下一个周期？ 可以按正常节奏排，但要先确认这条公告之外没有落后的修复，并把核查结论记下来。
没有可升级的版本怎么办？ 先断可被利用的那一层入口，例如把对应功能临时收口，再评估迁移成本。
公告说需要凭据就不急吗？ 需要凭据把攻击门槛抬高，但不改变支持期判断，仍要按版本跟进。
多久核对一次公告？ 按发布节奏设固定检查点，比按事件临时找更可靠；命中自己引擎或模块的要单独记处置台账。