重新打开标准是什么
漏洞验证通过之后，还要回答一个问题：修的是这一个入口，还是这一类问题。如果换个小写扩展名、换个参数通道、换个接口就能绕过，那就该重新打开。重开标准要在合同或项目章程里前置写明，触发条件、证据要求与期限计算方式都约定清楚，执行时双方照章办事，不必反复协商。
基本信息
| 触发条件 | 仍可触发，或用简单变体（编码变换、参数通道变化）可绕过 |
|---|---|
| 证据要求 | 新请求响应片段 + 时间戳 + 复现路径 |
| 状态处理 | 台账回退为未修复，保留原编号 |
| 期限处理 | 重新计算到期日并通知责任人 |
| 前置约定 | 写进合同或项目章程，避免验收时争议 |
典型使用场景
- 上传校验只拦常规扩展名，大小写混合仍可通过
- 注入过滤只覆盖主参数，排序或筛选字段仍可注入
- 越权修复只在前端隐藏入口，直接请求接口依旧成功
- 校验逻辑写在客户端，绕过前端即恢复原状
- 修复只覆盖主站，同源的其他域名未同步更新
重开记录示例
重开记录示例
F-04 上传校验：
修复后常规扩展名被拦截（初验通过，证据 E-28）
变体验证：扩展名大小写混合仍可上传 -> 重开
新证据：E-31（2026-10-25 10:12，请求响应片段）
状态：回退为未修复（保留原编号 F-04）
新到期日：2026-11-02，已通知系统责任人变体类型与验证要点
| 变体类型 | 验证要点 | 判定建议 |
|---|---|---|
| 编码变换 | 大小写、URL 编码、双重编码 | 能绕过即重开 |
| 参数通道 | 同名参数不同位置、头部传参 | 任一通道可绕过即重开 |
| 接口变体 | 同功能的其他接口与旧版本接口 | 未覆盖的入口可绕过即重开 |
| 部署差异 | 多节点或多域名版本不一致 | 任一节点未修复即重开 |
重开是验收的正常环节而非追责：把口径前置到合同里，双方对什么算修好了理解一致，过程就顺畅得多。
变体验证要控制范围：只验证与原问题同类、构造简单的绕过方式即可，不做深入利用与扩展测试，避免超出当轮授权范围。