# PHP Exploit Chain Audit

> PHP 利用链/POP(回弹)链聚合器。把已产出的各类漏洞报告按“前置条件满足”串成可利用链路叙事（不新增证据点字典）。

- Skill: `0xshe/php-exploit-chain-audit` (Agent Skill)
- Install (CLI): `npx skillmds@latest add 0xshe/php-exploit-chain-audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/0xshe/php-exploit-chain-audit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: 0xshe (https://skillmd.com/u/0xshe)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/0xshe/php-exploit-chain-audit

---


# 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
```

## 输出模板（强制）
必须包含以下结构（不得省略）：

```markdown
# 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 后无可包含/可执行面），则不要强行输出链；在“未能串联原因清单”解释为什么。