PHP 跨漏洞利用链聚合（php-exploit-chain-audit）

目标：将 vuln_audit/*_{timestamp}.md（以及可能的 auth_audit/*_{timestamp}.md）里的已确认/待验证漏洞，基于“可利用前置条件”串联成跨阶段利用链，并输出可观测的利用链叙事。

关键约束

• 不新增 EVID_* 证据点字典，也不要求 php-route-tracer 直接输出额外契约字段。
• 不复写每条漏洞的完整修复建议：只在链路层说明“为何下一步前置条件成立/不成立”。
• 允许输出“链路可利用性”：以构成链的最弱环节（任一环节不可利用/证据缺失）决定链整体状态。

输入依赖（建议）

• vuln_audit/*_{timestamp}.md：来自各 sink 子 skill 的漏洞报告集合（包含编号、可利用性、触发条件、位置证据与数据流链）。
• auth_audit/auth_audit_report_{timestamp}.md：用于补充链路中“鉴权门槛”是否一致（如漏洞链经过不同路由）。
• route_tracer/：如果需要补充“同一 route 的 sink 执行证据”，可通过漏洞报告中的 trace 证据引用回溯（不强制）。

产出目录结构（建议强制）

输出到：

{output_path}/exploit_chain/exploit_chains_{timestamp}.md

输出模板（强制）

必须包含以下结构（不得省略）：

# Exploit Chains (PHP) - Aggregation

项目路径: {source_path}
生成时间: {timestamp}

---
## 1) 利用链总览表
| chain_id | 链路类型 | 起点漏洞(编号) | 中间漏洞(编号) | 终点漏洞(编号) | 链路可利用性 | 关键依赖(路由/前置条件) |
|----------|----------|----------------|-------------------|------------------|----------------|------------------------------|
|          |          |                |                   |                  |                |                              |

---
## 2) 最短利用链（强制至少 1 条；若无则输出“未发现可拼接利用链”）
chain_id: {id}

### 2.{n}) 链路逐步叙事（按顺序）
Step 1: {漏洞编号}（类型 {SQL/CMD/FILE/WRITE/UPLOAD/DESER/TPL/EXPR/...}）
- 触发路由/入口：{route info from vuln report}
- 可利用性：{✅/⚠️/❌/🔍}（来自漏洞报告“可利用性”字段）
- 前置条件是否满足：{是/否/待验证}（解释依据：鉴权门槛、输入可控性、trace_status）

Step 2: {漏洞编号}
- ...

Step Final: {终点漏洞编号}
- 为什么它是终点（导致最关键的敏感操作）：{从 vuln report 中提取的结论性描述；不需要再堆证据点细节}

### 关键证据引用（链路级）
按 Step 顺序列出：
- {漏洞报告文件名}:{漏洞编号}（从该漏洞报告中提取“触发条件/可利用性前置条件/PoC 所需路由”）

---
## 3) “未能串联”的原因清单（强制）
列出至少以下类别：
1. 缺少关键落点/可访问性证据（例如 WRITE/UPLOAD 后未形成可读/可执行面）
2. 路由鉴权不一致（链上部分漏洞需要的权限与另一路由不匹配）
3. trace_status 不满足（PARTIAL/UNRESOLVED 导致无法确认链路可利用）
4. 需要特定环境依赖（🔍）

每条原因必须至少引用 1 个具体漏洞编号（来自 vuln_audit）。

链路类型建议（用于聚合，不强制）

建议从以下方向优先生成链（存在则写入，不存在就略过）：

• 落点写入/覆盖 -> 包含/读取 -> 代码执行（WRITE/UPLOAD/ARCHIVE -> FILE -> CMD/TPL/TPL->EXPR->CMD）
• 落点写入 -> 模板/表达式利用（WRITE -> TPL/EXPR）
• 对象注入（DESER） -> 后续敏感操作（FILE/CMD/WRITE 等，若漏洞报告能证明链式触发）

链路可利用性计算（强制规则）

chain 可利用性由链路最弱环节决定：

• 若所有 Step 的可利用性均为 ✅ 已确认，则链路为 ✅ 已确认
• 若任一 Step 为 ⚠️ 待验证（且非仅信息性缺失），则链路为 ⚠️ 待验证
• 若任一 Step 为 ❌ 不可利用，则链路为 ❌ 不可利用
• 若任一 Step 为 🔍 环境依赖，且无法在其它 Step 中兜底，则链路为 🔍 环境依赖

实操输出要求

• 必须使用“漏洞报告里的编号”作为链的 Step 纽带（禁止用抽象描述替代编号）。
• 若只能找到孤立漏洞且无法满足“前置条件承接”（例如 WRITE 后无可包含/可执行面），则不要强行输出链；在“未能串联原因清单”解释为什么。