表单模块的远程执行修在 6.2.12，升级窗口怎么排
升级窗口怎么排，起点不是「今晚几点动手」，而是先确认自己是否落在受影响区间。Drupal 表单模块 Webform 的这条危急级远程代码执行公告（编号 SA-CONTRIB-2026-175，发布于 2026 年 9 月 23 日）给出的写法是：小于 6.2.12，以及大于等于 6.3.0 且小于 6.3.1，修复分别落在 6.2.12 和 6.3.1。区间读错，窗口排得再准也没有意义。
影响区间和修复版本怎么读
安全公告的版本描述通常有三层信息，读法各不相同。第一层是受影响分支，可能不止一条，像这条公告就同时覆盖两个版本线；处在其中任一条都要处理。第二层是修复版本，注意它通常对应多条分支各有一个版本号，不要以为存在一个「万能最新版」。第三层是严重级别与触发条件，「危急」意味着可远程触发，但真正决定优先级的是这个功能在你的站点上是否匿名可达。
读区间时最容易犯的错是只看主版本号。6.2 与 6.3 听起来接近，实际是分属两条维护线，各自的修复修订号不同。把自己当前版本逐条代入，比「看是不是最新」可靠得多。
判断站点是否命中要看哪三个位置
第一个位置是依赖锁定文件，例如 composer 锁文件里记录的机器名与版本，它反映的是实际安装结果，而不是后台页面显示的名称。第二个位置是站点里是否存在该模块提供的功能：表单、问卷、上传组件、以及任何由它注册的公开路径。第三个位置是入口是否匿名可达。用无痕窗口打开站点的表单页，看能否在不登录的情况下提交，能提交才说明这条远程执行对你构成现实风险。
| 检查结果 | 含义 | 窗口建议 |
|---|---|---|
| 版本落在区间内，且表单匿名可提交 | 现实风险最高 | 当日低峰处理，先临时关闭提交 |
| 版本在区间内，但该功能未启用 | 潜在风险 | 排进本周窗口，可先卸载模块 |
| 版本已在 6.2.12 或 6.3.1 之后 | 不命中 | 记录核查结论，不打扰线上 |
| 未安装该模块 | 不相关 | 从清单移除，避免下次重复排查 |
升级窗口按流量低峰怎么排
排序原则有三条。把提交类功能的中断时间压到最短，所以动手前先确认表单量最低的时间段；一次只动一个变量，避免同时升级主题、模块与核心，出问题时无法归因；预留回滚时间，升级动作本身可能只要十几分钟，但回滚窗口要按小时准备。另外，公告发布日期不等于修复可用日期，若模块还有其他近期公告，应把它们合并进同一个窗口，减少业务中断次数。
升级后要验证表单与提交数据的清单
升级完成的判据是功能可用，而不是版本号变了。至少验证五项：既有提交记录能否正常读取；新建表单能否提交并收到通知；附件上传、邮箱通知这类下游动作是否仍在；验证码校验是否还生效，有些升级会顺手重置校验开关；以及后台权限是否需要重新签发会话。数据表结构变更时，建议先跑一次只读校验再放开流量。
AnQiCMS 里表单防机器人的配置位
AnQiCMS 把表单侧的常见风险做成了内置开关：reCAPTCHA 验证码可直接接入表单，用来压制批量提交与垃圾留言，但验证码不能替代版本管理——它能挡住机器人，挡不住利用代码构造的合法请求，因此要与提交频率限制一起使用。另一侧是备份与恢复：数据（含静态文件）备份在升级前先做一次，确保结构变更导致异常时可以整体回退，而不是手工修补数据表。两者搭配的效果是把「升级窗口」的风险从不可逆变为可回退。
常见问题
修复版本已发布但站点暂时不能停，能先只做配置收紧吗？ 可以，思路是关闭该模块的匿名提交入口或暂停对应表单，把远程触发条件切断。这只是争取时间，配置收紧不覆盖代码层修复。
跨版本线升级会不会丢数据？ 风险主要在数据表结构与配置项，而不是提交记录本身。升级前做可恢复备份、升级后按清单核对读取与提交两条路径，就能把风险控制在可回退范围内。
公告里的严重级别要怎么取舍？ 看是否能匿名触达以及是否影响数据写入。可匿名触发且能改数据的按当日处理，仅登录后可达的排入常规窗口。