PHP 利用链/POP(回弹)链聚合器。把已产出的各类漏洞报告按“前置条件满足”串成可利用链路叙事(不新增证据点字典)。
Scanned 9/4/2026
Install to Claude Code
npx -y skills add NeverSight/skills_feed --skill php-exploit-chain-audit --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Php Exploit Chain Audit?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/neversight-php-exploit-chain-audit)More formats (shields.io, HTML) on the badges page.
---
name: php-exploit-chain-audit
description: PHP 利用链/POP(回弹)链聚合器。把已产出的各类漏洞报告按“前置条件满足”串成可利用链路叙事(不新增证据点字典)。
---
# 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 后无可包含/可执行面),则不要强行输出链;在“未能串联原因清单”解释为什么。
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!