CVE-2026-9082 公告里 Drupal 7 不在受影响列表，为什么停更的老系统还是睡不踏实

Drupal 7 不在 CVE-2026-9082 的受影响版本列表里，原因很直接：这条 SQL 注入问题出在仍在支持期的核心分支上，而官方对 Drupal 7 的安全维护早在 2025 年 1 月 5 日就结束了。停更的老系统让人睡不踏实的，从来不是某一条公告有没有点名它，而是从那一刻起，新出的问题连被写进公告的机会都没有——你既等不到修复版本，也等不到风险提示。

公告里为什么没有 Drupal 7

CVE-2026-9082 对应 Drupal 核心通告 SA-CORE-2026-004，性质是 SQL 注入。第三方安全机构 HeroDevs 在核对公告后给出的判断是 Drupal 7 不在这条漏洞的影响范围内，因为它不包含被改动的那段核心代码路径。这是一次范围判断，不是健康证明：公告的写法是先声明哪些仍在服役的分支有问题，停止维护的分支默认不出现在任何一栏里，既不写「受影响」，也不写「不受影响」。

换句话说，「没被点名」这件事本身没有提供安全信息，它只告诉你这一条编号的修复补丁不会发布给这个版本。

这次没中，和还能安全跑，是两件事

还在服役的分支出事，会有公告、有修复版本、有升级建议，运维动作是照着执行。停止维护的分支出事，问题照样会被研究者发现，只是发布渠道换成了第三方公司的博客、安全会议，甚至漏洞交易市场——这些地方不会给你升级路径。

此时站点的暴露面不会因为没进公告而收窄：

• 老的第三方扩展与主题失去了维护者，它们的代码不再被审计，也不会被打补丁；
• 配套的脚本运行时停在旧版本上，运行时的新问题要自己盯；
• 告警与日志里没有对照基线，出事时难以判断是入侵还是故障；
• 数据往往只剩线上那一份在线副本，恢复要靠运气。

停更的老系统实际敞开着哪几道门

判断风险时，把「这一条漏洞」换成「这一类入口」更实用。停更站点常见的入口有四类：管理后台的登录面、公开的表单与评论、带参数的列表与搜索接口、以及上传目录里的静态文件。这四类入口的防护强度取决于当前部署的那套代码，而停更意味着它们的加固节奏已经停住，攻击面却仍在被持续扫描。

决定迁移之后，动作顺序比速度更重要

迁移窗口里最先做的不是搬数据，而是把退路留下：数据连同上传的静态文件一起做备份，并实际执行一次恢复验证。只备份不验证的做法，出事时常常发现恢复出来的东西对不上。

第二步是收敛内容状态。把文档按正式文档、草稿、待发布、回收站四类清一遍：能删的草稿不要带进新站，回收站里的历史内容确认是否还要留档。状态干净了，迁移后的数据核对才有可比性，也避免出现新站里多出一批无人认领的待发布内容。

第三步才是切换与验证：先迁内容与结构，再逐条核对 URL 的跳转关系，最后把登录、表单、评论这几类入口跑一遍真实提交。

短期不迁移，可以先做的防护分层

迁移排不上的时候，把入口收窄比等待补丁更有效。应用侧要做的是：后台与接口用 JWT 认证限定调用方，内容侧开启敏感词过滤与关键词替换，采集面用干扰码提高搬运成本，让自动化程序拿到的不是干净全文。注入类问题的处理思路也可以参考独立部署系统的做法——AnQiCMS 在 v3.6.6 里修的两类问题就是典型样本：列表的排序参数要做注入校验，站点切换登录改用一次性票据，避免凭证被伪造。这两处都不是靠前置设备挡掉的，而是在应用层把数据入口收窄。

常见问题

Drupal 7 现在还能修这个漏洞吗？ 官方分支不会再为它发补丁。要继续跑，只能靠第三方提供的长期支持，或者把站点迁到仍在维护的系统上。

怎么判断自己站点的风险有多高？ 先看它是否公网可达、后台是否限制登录来源、扩展是否还有人在维护，再看有没有可用的备份与恢复演练记录。前两条决定被入侵的概率，后一条决定出事后的损失。

迁移最容易漏掉什么？ URL 结构的对应关系和上传文件。前者影响既有收录与访问，后者会让历史图片在新站上成片缺失，而这两项都能在备份阶段提前核对。