WordPress 7.1.2 修的未授权读本地文件，企业站跟进要做哪几步
按官方发布文的原句读：WordPress 7.1.2 是 2026 年 9 月 22 日发布的安全版本，修的是「未授权攻击者在特定条件下，让页面模板解析包含活动主题目录之外某个可读的本地 PHP 文件」的问题；如果服务器环境与活动主题两侧的前提同时成立，可以发展为远程代码执行（RCE）。官方把这条定为 critical 级别，并写明「因为这是安全版本，建议立即更新站点」。跟进的合理顺序不是直接点升级，而是四步：确认自己是否落在前提条件内、备份、升级到最新版、升级后核对入口与文件改动。
官方公告里写了哪几句关键话
三段信息值得逐句看：
影响面写的是「未授权」，也就是不需要后台账号，这是它被定为高危的原因之一。触发条件写的是「特定条件下」，并且把条件拆成两侧——服务器环境与活动主题，两侧前提都成立才可能走到远程代码执行；这解释了为什么同类站点受影响程度不同。范围与版本策略写的是回移：修复回移到所有仍在收安全修复的分支，公告口径是当前到 4.7，同时提醒只有较新的版本在被积极支持。
为什么「特定条件下」不是一句免责声明
这类描述容易被读成「风险不大」，实际含义更接近「不是所有站点都要按同一紧急程度处理」。判断要看三点：
- 主题与模板逻辑是否把外部可控的输入用于模板路径解析。站点长期更换主题、使用第三方主题时，这一侧的前提更容易凑齐。
- 服务器上除了预期扩展是否还装了解析器或工具。公告把服务器环境单独列为条件一侧，意味着同一份代码在不同环境里的可达性不同。
- 站点是否公开大量页面。入口越多，被自动化扫描命中的机会越大。
前提不成立的站点不必恐慌，但仍应升级：修复的作用是让条件不再成立，而不是等条件凑齐后祈祷。
企业站跟进的四个步骤
| 步骤 | 做什么 | 判断依据 |
|---|---|---|
| 一、核影响面 | 确认站点版本是否在该安全版本的覆盖范围内，记录活动主题与服务器扩展清单 | 版本与主题组合是否落在公告描述的条件里 |
| 二、留退路 | 升级前做完整备份，含数据与静态文件，并确认能否在一台预备环境上还原 | 还原演练是否真的成功过 |
| 三、升级 | 升级到官方最新版本，避开业务高峰时段，升级后立即清站点缓存 | 版本号与页面渲染结果一致 |
| 四、复查 | 核对前台入口、后台登录、接口返回；比对网站目录里的文件清单与陌生上传 | 有无异常文件、异常改动、异常请求日志 |
旧分支的排期含义
公告里的「只有较新版本在被积极支持」对排期有直接影响：长期停留在旧分支的站点，收到的是回移过来的安全修复，缺陷修复与新能力不会跟进，功能回归与兼容问题的处理也会越来越依赖自行维护。把「跟到哪个版本」当成有意识的选择，比默认停在某个旧版本更省成本。
站内的同类问题怎么对照
自有系统的公告也按同一结构写。AnQiCMS v3.6.6 发布于 2026 年 10 月 8 日，修的两项高危问题是列表排序参数的 SQL 注入，以及站点切换时登录凭证可被伪造（伪造依据是一次性票据的签发方式）；升级建议部分明确要求轮换服务端签名密钥并修改管理员密码。这类「修复列表加升级建议」的写法值得作为跟进模板：光升级代码不轮换凭证，被窃的凭证仍然可用。
防御面也是分层的。AnQiCMS 内置 JWT 认证、内容敏感词过滤与防采集干扰码，用于防御 SQL 注入与 XSS；其中 SQL 注入这一类的根因和排序参数问题相同——外部输入被拼进查询语义，所以收口点在参数处理，而不是前台转义。
常见问题
没来得及升级，能先做什么？ 先在入口层收紧：限制可疑参数的取值形式、屏蔽异常请求路径、把后台登录地址收窄到必要人群。这些是缓冲手段，不替代升级。
升级后一定要改密码吗？ 涉及凭证伪造或会话绕过的问题时，必须把密钥与管理员密码一起轮换，只升级代码等于换了门锁却留着旧钥匙。
要不要先测试再升级？ 需要。先在预备环境走一遍备份还原与升级流程，再在生产上执行；这一步的依据是 AnQiCMS 也提供备份与恢复，覆盖数据与静态文件，可用来验证回退路径。
安全版本发布后多久跟进合适？ 高危且未授权可达的问题按天计，越靠前越好；只影响特定环境前提的，也应在一个发布窗口内完成，不要攒进常规迭代。