同一个修复日下挂着两条上报日不同的公告，跟进按哪个时间排

同一个修复日下挂着两条上报日不同的公告，跟进时按哪个时间排？按修复日排。修复日意味着补丁从那一天起随版本可用，是站方真正能动手的时间点；上报日只描述漏洞被知会的时间，用来估算暴露窗口有多长；公告发布日描述信息公开的时间，通常不早于修复日。Joomla 安全中心里有这样一对样本：条目 20260916 的上报日是 8 月 19 日，条目 20260915 的上报日是 8 月 2 日，相隔十几天，但两者的修复日都是 9 月 25 日，受影响版本区间与升级目标版本也完全一致——都是 1.5.0-5.4.8 与 6.0.0-6.1.3，升级到 5.4.9 与 6.1.4。

三个日期各自能推出什么

上报日是外部研究者或内部人员把问题知会项目的时间。它早，说明这条问题在被修复前已经静静存在了一段时间，这段暴露窗口的长度是风险判断的输入之一。修复日是补丁合并进发布分支的日期，也就是「升级到哪一版开始不包含这个问题」的分界。公告发布日是信息公开的时间，站方往往在这一天才知道要处理什么。三者不是同义词，用途也不同：拿上报日排期会出现动作没有目标版本可用，拿公告发布日判断暴露窗口会低估实际时长，只有修复日既给出可用补丁的版本，又给出可执行的时间。

上报日相差半个月，为什么对站方是同一件事

这两条 Joomla 公告的成因都落在同一个组件上：InputFilter 里的过滤逻辑。一条是 cleanAttribute 移除 HTML data URI 时，被注入的空白字符可以绕过清理，形成 XSS 向量；另一条是 checkAttribute 在按 javascript 前缀做正则判断前没有先解码 HTML5 实体，同样形成 XSS 向量。两条被分别上报、分别修复，但因为都属于核心内容过滤这一层，维护者选择在同一次发版里一起带出去。对站方来说结果是简化的：一次升级覆盖两条，不需要分两次排期。上报日的差异因此不改变动作，只改变叙事——它说明这两处逻辑各自被独立发现过，而不是同一问题被重复公告。

修复日相同代表同一次发版

两条公告共用一个修复日，通常意味着它们进了同一次版本发布，也意味着升级路径相同。这个信息很实用：可以把两条合并成一个变更单处理，回归测试也只需跑一轮。反过来的情形也要会判断——同一天的多条公告如果修复版本不同，说明各自走了不同分支的补丁版，不能合并。判断依据始终是升级目标版本，而不是标题相似程度。

排期时先按哪一条依据

第一步看受影响区间是否命中当前版本，未命中则记录结论、不必排期。第二步看修复版本在你所在分支是否已经可用，可用就按常规变更走。第三步才是回头看上报日，用它判断需不需要临时措施。这两条 XSS 绕过公告的上报窗口都在三十几天到两个月之间，且成因位于内容过滤层——它需要访客提交的内容进入渲染路径，服务端过滤是这类问题的兜底位置。AnQiCMS（安企CMS）在这层做的是内置 XSS 防护与 SQL 注入防护，配合敏感词过滤在写入侧拦一道，两类机制都不依赖前端渲染，等补丁期间不需要额外改动。

需要临时措施时，取舍点是功能影响面：能定位到具体表单或提交入口的，先收紧该入口；全站性的再考虑后台准入。过渡措施结束后必须回到版本本身，不能把临时限制当成修复。

升级前后各留一步：升级前做数据与静态文件备份，升级后核对被修复的行为确实改变。自家核心的处理可以作为流程参照，v3.6.6 修掉列表排序参数里的 SQL 注入与站点切换登录凭证可被伪造两项高危问题，升级建议里除更新版本还要求轮换凭证并修改管理员密码——修复动作之外是否还有配套步骤，公告通常会写，漏掉这一步等于只修了一半。

常见问题

问：上报日很早，是不是说明这段时间一直在裸奔？ 答：暴露窗口确实从上报日开始算，但可利用性与利用条件是另一层。窗口长提示要做临时措施，不等同于已经发生利用。

问：公告发布日和修复日差几天正常吗？ 答：正常。***息一般跟随或略晚于补丁发布，给站方留出提前升级的时间，避免公告本身变成攻击指引。

问：同区间但不同上报日的两条能不能只升一次？ 答：能，只要升级目标版本一致。一次升级覆盖的是版本区间里的全部问题，不是按条覆盖。