公告里的漏洞没有可升级的受支持版本，站点先断哪一层
安全公告指出漏洞所在项目已经没有受支持的修复版本时，站点应该先断开哪一层？先断开的是这个功能本身——停用或卸载，而不是先去加固别处。某内容管理系统 Drupal 在 2026-October-07 的公告 SA-CONTRIB-2026-196 可以直接作样本：项目是 Orphans Media，风险评级 Critical 16 / 25，漏洞类型这一栏写的是 Unsupported，受影响版本写作全部版本，公告明确说明这个已知安全问题没有被修复、正在使用这个项目的站点应当卸载它。同日清单页里还有一条同样标注 Unsupported 的公告（SA-CONTRIB-2026-193）。
公告里没有可升级版本意味着什么
有三层含义。第一层最直接：没有修复版本可打，升级这条路走不通，跟进动作从「打补丁」变成「换实现或者不要这个功能」。
第二层是维护状态。公告把类型写成 Unsupported，等于确认这个项目不再接受安全修复，今后再出问题也不会有补丁。留着它，承担的是持续风险，不是一次性风险。
第三层是评级要重读。样本公告的维度里，攻击复杂度为 Complex、需要管理员权限，而机密性与完整性影响都标为 All，利用状态标注为理论可行。这组维度说的是「门槛不低、一旦成立影响很广」——所以处置重点在断可达路径，而不是判断它是否已被利用。
不能因为「需要管理员权限」就把它排到低档：管理员类入口往往是配置类动作，站点里通常不止一个账号有这类权限。
先停用还是先加固：顺序怎么定
顺序是先停用、再加固、后评估。反过来做（先加一层防护、功能继续跑）会拉长暴露时间，而这类问题恰恰没有收口的终点。
具体动作分四步：
- 确认这个功能在站点里被谁用、用得多不多。低频且非核心的功能可以直接停；核心流程上的功能要先准备替代。
- 停用或卸载该项目。公告写明建议卸载的，就按卸载处理，只关闭开关不算处理完。
- 收窄入口。把后台地址收到可信网络，把不需要的外部接口域保持关闭；这一步压缩的是残余风险。
- 评估数据影响。停用前该项目读写过的内容、文件与配置项要逐项核对，确认没有留在原位可被读取的产物。
有补丁可用时，第一步是排升级窗口；没有补丁时，第一步是决定这个功能还要不要。这是两种处置最本质的差别。
没有补丁时能争取的是什么
争取的是时间和可见性，不是免疫。
时间靠收窄：入口越窄，被试错的机会越少，替代方案就有了排期空间。可见性靠日志与核对：文件清单、异常请求、正文与配置的变化，都要能在事后被看出来。
另一件能争取的是回退能力。卸载或停用会改数据结构、清掉配置，一旦替代方案上线后不合用，没有回退点就得手工重建。这一步在两种处置里都容易被跳过：有补丁时觉得「升级不会出问题」，无补丁时觉得「先保命再说」。
备份与站点隔离在这里的作用
AnQiCMS 支持备份与恢复，范围覆盖数据含静态文件。遇到无补丁可用的公告时，先做一次完整备份再动手，它同时充当三个角色：回退点、比对基准、证据留存——停用前后各留一份文件清单，才知道这个项目在站点里到底写过什么。
多站点场景还有一层：同一套后台管多个站时，某个站装了停止维护的项目，其他站要逐个核对。AnQiCMS 的多站点管理让各站独立配置，停用动作也要按站执行，不能假设一次操作覆盖全部。
替代方案上线时按同样的顺序走：先在新实现上验证，再从旧位置移除数据，中间保留回退点。
常见问题
能不能自己改代码顶上？ 不建议把它当处置方案。停止维护的项目缺少的是长期维护承诺，临时改动能挡住这一个已知问题，挡不住后续问题，也得不到安全更新。
功能停不掉，业务要用怎么办？ 那就把这个功能从公开可达路径挪走：只在内网或运维时段可达，同时把可替代的部分先迁走。要在报告里写清这是过渡状态和收回时间。
怎么判断其他项目是不是也停止维护了？ 看三点：最近一次更新距今多久、issue 与公告里有没有明确停止维护的表述、公告是否把类型标为 Unsupported。任一成立就要把它列入替换清单。
卸载之后要复查什么？ 三类残留：写入正文或配置的内容、留在存储里的文件、被其他功能引用的标识。逐类清完再观察一次入口与日志。