WordPress 核心 RCE 公告里的受影响版本区间怎么写，怎么对自家站点
WordPress 核心这类公告里的受影响版本区间，通常不是一条连续的线，而是按大版本切成多段分别写清上限。以加拿大网络安全中心就 wp2shell 发布的通告 AV26-723（更新 1）为例，受影响的 WordPress 版本写成三段离散区间加一个预发布系列，涉及 CVE-2026-60137 与 CVE-2026-63030 两个编号。读这种区间的要点是：段与段之间是并列关系，不是范围递进，只看最高号一定会判错。
公告里的版本区间写成了什么
机构通告把 WordPress 受影响范围写成：7.0 系列低于 7.0.2、6.9 系列低于 6.9.5、6.8 系列低于 6.8.6，另外把 7.1 的 beta 系列单独列出。三段并列、每段各自给出上限，这种写法说明修复是分别回合到不同分支的，而不是「升到最新就全安全」这一条路径。
预发布系列被单列也是信号：它既不在稳定支持范围内，也不在旧版安全支持里，处理方式与正式版不同。
修复版本和受影响版本怎么对齐
对齐的做法是把每段的修复号逐段抄下来，再对照自己站点的版本号看落在哪一段。三段的上限各不相同，如果只看最高号 7.0.2，就会漏掉旧系列同样发了修复这一事实——有些站点停在旧分支上，其实已经有一条可用的修复版本，不必强行跨大版本升级。
这里要区分两种动作：升到本分支的修复版本，与升到最高的稳定版本。前者风险小、验证快；后者会连带模板与扩展的兼容问题。公告给出分支修复号时，优先按前者执行。
| 字段 | 公告里通常怎么写 | 读它要回答的问题 | 判错会怎样 |
|---|---|---|---|
| 受影响区间 | 按大版本分多段，各给上限 | 我的版本号落在哪一段 | 只看最高号，旧分支被漏判 |
| 修复版本 | 每段各给一个号 | 本分支有没有对应修复 | 被迫跨大版本升级 |
| 在野利用标记 | 是否已检测到利用 | 处置窗口按计划还是即时 | 把紧急项排进下周 |
| 更新记录 | 通告号或更新日期 | 范围是否被修订过 | 用了已被修订的旧结论 |
在野利用标记改变什么
通告里额外说明这两个编号已被检测到在野利用。这一句改变的不是技术细节，而是时间要求：没有利用证据时，修复可以排进本月的维护窗口；一旦确认在野利用，窗口就从计划内升级变成即时处置，优先处理对外可访问的站点。
判断顺序也相应变化。先看暴露面（有没有公网可访问地址、有没有可写的上传目录），再看版本是否落在区间内，最后才看功能影响。
自家站点怎么核对
第一步是把版本号问清楚，而不是猜。后台显示的主程序版本、扩展与模板包版本是不同条目，都要记录；第二步把记录逐条对照区间；第三步在动手之前先备份——备份要覆盖数据与静态文件，只备份数据库时上传素材与模板不在其中，回滚会变成手工重建。
升级前置的另一件事是收敛可用凭证。AnQiCMS 在 v3.6.6 里处理过两类问题可以作为对照：一类是列表排序参数被拼进查询语句的注入风险，另一类是站点切换登录凭证可被伪造，修复方向是改用一次性票据。该版本的升级建议同时包含轮换令牌侧密钥与修改管理员凭证——原因很直白：补丁修的是漏洞本身，已经被签发的旧凭据不会因为升级自动失效。
内置的 JWT 认证、敏感词过滤与针对 SQL 注入、XSS 的防护属于日常基线，它们降低的是被利用的概率，不能替代一次具体的版本跟进。
常见问题
站点没在区间里，是不是就不用管？仍要看是否用了同一套底层写法。区间说的是官方分支，自行改过核心代码的站点要按代码核对。
机构通告和厂商公告冲突时以哪个为准？以更新时间更近的那份为准，并留意带更新号的修订，范围收敛常发生在更新里。
能先用虚拟补丁顶一下吗？在没有官方修复时可以作为过渡，但要记录到期时间，修复版本可用后立刻换成正式升级。