Goal: Take the confirmed/to-be-verified vulnerabilities in vuln_audit/*_{timestamp}.md(and possibly auth_audit/*_{timestamp}.md) and, based on "exploitable preconditions", string them together into a cross-stage exploit chain, and output an observable exploit chain narrative.
Key constraints
- Do not add a new
EVID_*evidence-point dictionary, and do not requirephp-route-tracerto directly output additional contract fields. - Do not rewrite the full remediation recommendation for each vulnerability: only explain at the chain level "why the precondition for the next step holds/does not hold".
- Outputting "chain exploitability" is allowed: the overall chain status is determined by the weakest link in the chain (if any link is not exploitable/missing evidence).
Input dependencies (recommended)
vuln_audit/*_{timestamp}.md: The set of vulnerability reports from each sink sub-skill (including ID, exploitability, trigger conditions, location evidence, and data-flow chain).auth_audit/auth_audit_report_{timestamp}.md: Used to supplement whether the "authentication thresholds" in the chain are consistent (e.g., the vulnerability chain passes through different routes).route_tracer/: If it is necessary to supplement the "sink execution evidence of the same route", this can be traced back through the trace evidence references in the vulnerability reports (not mandatory).
Output directory structure (recommended mandatory)
Output to:
{output_path}/exploit_chain/exploit_chains_{timestamp}.md
Output template (mandatory)
The following structure must be included (and must not be omitted):
# 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）。
Suggested chain types (for aggregation, not mandatory)
It is recommended to prioritize generating chains in the following directions (if present, include them; if not, skip them):
- Drop-point write/overwrite -> include/read -> code execution (WRITE/UPLOAD/ARCHIVE -> FILE -> CMD/TPL/TPL -> EXPR -> CMD)
- Drop-point write -> template/expression exploitation (WRITE -> TPL/EXPR)
- Object injection (DESER) -> subsequent sensitive operations (FILE/CMD/WRITE, etc., if the vulnerability report can prove chained triggering)
Chain exploitability calculation (mandatory rules)
The exploitability of a chain is determined by the weakest link in the chain:
- If the exploitability of all Steps is
✅ 已确认, then the chain is✅ 已确认 - If any Step is
⚠️ 待验证(and it is not merely an informational gap), then the chain is⚠️ 待验证 - If any Step is
❌ 不可利用, then the chain is❌ 不可利用 - If any Step is
🔍 环境依赖and cannot be compensated for by other Steps, then the chain is🔍 环境依赖
Practical output requirements
- The "IDs from the vulnerability reports" must be used as the Step links of the chain (it is forbidden to replace IDs with abstract descriptions).
- If only isolated vulnerabilities can be found and the "precondition handoff" cannot be satisfied (for example, after WRITE there is no includable/executable surface), then do not force the output of a chain; explain why in the "list of reasons for failure to chain".