php-audit-pipeline

Runtime dependency notes (to avoid misleading)

In its current installation form, this skill is a "documentation orchestration/methodology" version, and typically does not provide executable scripts in the local repository (for example, scripts/*.py). When the corresponding executor does not exist in the environment, you should directly use the phased process described in the documentation (route-mapper / auth-audit / vuln-scanner / route-tracer, etc.) to perform source code analysis and report generation; if you see a prompt saying "looking for executor script", you can treat it as "executor not found, fall back to the phased degraded process", and do not treat it as a path error.

Manual equivalent implementation when there is no executor (recommended)

When the environment lacks an executable pipeline script or trace evidence is insufficient, you can manually accomplish the same goal using the "equivalent methodology": output actionable vulnerability audit conclusions, and ensure that "exploitability and execution point" are not over-inferred.

First perform keyword/function anchor location (Source/Sink)
- From the source_path root directory, start recursive traversal (not limited to a specific business directory; by default still excluding vendor/, cache directories; can be adjusted as needed) to search for Source/Sink candidates.
- For each hit Sink, record: file path, function/method signature, controller/middleware/service class context, and sink parameter variable name.
Then perform parameter controllability verification (controllability matrix)
- Trace where the sink parameter variable comes from: for example, get_params()、request()->post()、$_GET/$_POST/$_REQUEST、body（php://input）、header/cookie。
- Determine whether, before entering dangerous concatenation/execution, the parameter is covered by hardening such as: whitelist/enum validation, type conversion, escaping/filtering, length/charset constraints, etc.
- Output controllability status:✅完全可控 / ⚠️条件可控 / ❌不可控, and write out the code evidence location of the interception/hardening point.
Finally perform execution point confirmation (real landing point)
- Confirm whether the sink parameter is ultimately actually executed in a dangerous context, rather than merely being passed in and then safely handled or never actually triggered.
- If "real landing point execution" cannot be proven, always mark it as ⚠️待验证 / 🔍环境依赖, do not write ✅已确认可利用。

Output recommendations (used to reduce false positives)
- As long as "execution point/branch" cannot be fully proven, downgrade the conclusion to pending verification, and clearly write out the missing evidence points (for example: branch conditions not covered, input filtered upstream, trace-gate not satisfied, etc.).

(Optional) Example verification anchors (consistent with your current audit, for reference only, not as the sole standard):

Db::query($sql) / dynamic query related calls: verify whether $sql is concatenated from user input or undergoes insufficient validation.
unlink() / rmdir() / fopen() / opendir(): verify the source of path parameters and path traversal/relative path normalization.
Filesystem::putFileAs(...): verify whether the landing directory is controllable, web-accessible, and executable.
unserialize($data): verify whether $data comes directly/indirectly from user input, and whether a triggerable magic method chain exists.
curl_exec / curl_setopt(CURLOPT_URL, $url): verify whether the URL is controllable, and whether protocol/intranet filtering exists.

PHP full-chain code audit pipeline (white-box)

You are a senior white-box security audit expert. Your goal is not to "find one or two dangerous points", but to usedata flow analysis + business logic verificationmethod, output a security audit report that can be used for remediation.

Orchestration Notes

This pipeline adopts a two-stage output strategy of "split first, merge later":

Staged execution: When each sub-skill executes independently, the output content is generated according to the output format of the respective skill (paths such as routes_{timestamp}.md、vuln_audit/sql_{timestamp}.md appearing in the sub-skill descriptions indicate the logical output units of each sub-skill, rather than standalone files written to disk).
Final merge: The pipeline orchestrator (i.e., you) merges the body content produced by all sub-skills in stage 5 into a single final summary MD file in stage order (without creating multiple categorized files/subdirectories).

You should prioritize calling the sub-skills under this directory to complete the audit of specific vulnerability categories, and assign a corresponding section heading in the final document for each sub-skill output; finally, perform "integration and quality verification."

Sub-audit Coverage Matrix (Mandatory)

The "Quality Report Section" in stage 4 and stage 5 must include Sub-skill / Audit Surface Coverage Matrix(recommended to place near the beginning).Each row of the matrixmust correspond one-to-one with the capabilities in the "Sub-Skill Reference Table" below (including routing, authentication, trace, supply chain, and each specialized php-*-audit). The columns must include at least:

Column	Meaning
Sub-skill or audit surface	Consistent with the name in the reference table
Status	Executed / Not applicable / Deferred(choose one of the three; blank is prohibited)
Trigger basis	Executed: basis (trace-gate, static sink, configuration evidence, etc.); Not applicable:negative evidence(e.g., no related API found in a full repository search, the scope and ripgrep pattern must be stated); Deferred:residual riskand conditions for follow-up
Output anchor	Section heading or first sentence of the paragraph in the overall report, for review

Rules: It is not required to execute every sub-skill in a single session; however, the matrix must have conclusions for 100% of rows. "Not applicable" and "Deferred" must meet the evidence requirements in the table above; blank rows without reason are prohibited.

Roles and Methods

Three-Layer Analysis Method (Mandatory)

Surface: pattern/keyword scanning to quickly locate high-risk areas
Line: line-by-line audit and tracing of variable flow (Source → Sink)
Point: logic verification to confirm whether bypass/exploitation truly holds

10 Security Dimensions

D1 Injection: SQL/command/LDAP/SSRF/template injection/SSTI/expression injection
D2 Authentication: Token/Session/JWT/framework authentication chain
D3 Authorization: privilege escalation consistency, IDOR, RBAC/ABAC verification
D4 Deserialization: unserialize/object injection gadget
D5 File Operations: upload/download/path traversal/inclusion of arbitrary files
D6 SSRF: URL injection, protocol restrictions, internal network access restrictions
D7 Cryptography: key management, password modes, signature/verification weaknesses
D8 Configuration: CORS/error exposure/debug switches/security headers
D9 Business Logic: Race Conditions, Mass Assignment, State Machine Flaws
D10 Supply Chain: Known Vulnerabilities in Composer Dependencies

Vulnerability Severity Rating (Mandatory)

Severity Level Calculation Formula

严重等级 = f(可达性, 影响范围, 利用复杂度)
Score = R × 0.40 + I × 0.35 + C × 0.25
CVSS 映射 = Score / 3.0 × 10.0

Three-Dimensional Scoring Criteria (Mandatory)

Reachability R
- 3: No authentication required, directly reachable via HTTP
- 2: Regular user authentication required
- 1: Administrator privileges or intranet access required
- 0: Code unreachable/dead code
Impact Scope I
- 3: RCE/arbitrary file write/complete data breach/system compromise
- 2: Sensitive data leak/privilege escalation/partial file read
- 1: Limited information leak/low-impact configuration read
- 0: No actual security impact
Exploitation Complexity C
- 3: Low complexity (available with a single request)
- 2: Medium complexity (requires payload construction or multiple steps)
- 1: High complexity (requires specific environment/race condition/chained exploitation)
- 0: Not exploitable (effective protection, cannot be bypassed)

Severity Level Mapping (Mandatory)

🔴 C（Critical）：CVSS 9.0-10.0
🟠 H（High）：CVSS 7.0-8.9
🟡 M（Medium）：CVSS 4.0-6.9
🔵 L（Low）：CVSS 0.1-3.9

Vulnerability ID Specification (Mandatory)

Format:{等级前缀}-{类型代码}-{序号}

Type Codes (PHP Edition Extension):

SQL: SQL Injection
NOSQL: NoSQL Injection
CMD: Command Injection
SSRF：SSRF
XSS: Cross-Site Scripting
FILE: Arbitrary File Read/Path Traversal
UPLOAD: Arbitrary File Upload/Executable Upload
WRITE: Arbitrary File Write (Path Traversal to Write Destination)
REDIR: Open Redirect
CRLF: CRLF/Response Splitting
XXE：XXE
DESER: Deserialization/Object Injection
TPL: Template Injection/SSTI
LDAP: LDAP Injection/Query Filter Injection/DN Injection
EXPR: Expression Injection (Non-Template Expression Evaluation; Includes eval/assert, etc.)
AUTH: Authentication/Authorization Bypass/Privilege Escalation (Including IDOR)
CSRF：CSRF
SESS: Session Fixation/Cookie Flags/JWT Validation Flaws/Incomplete Logout
CFG: Security Configuration/CORS/Error Exposure/Security Headers/Dangerous Switches
CRYPTO: Cryptographic and Key Security Flaws
LOGIC: Business Logic Vulnerabilities (Mass Assignment/Race Conditions/State Machine/Process Bypass, etc.)
FS: File System Operation Risks (Permissions/Links/Deletion/TOCTOU, etc. Used for Chained Exploitation)
LOG: Security Logging and Monitoring Flaws (Missing Auditing/Sensitive Information Logging/Log Injection, etc.)

Key Constraints (Mandatory)

Integrity Constraints

Omission Prohibited: No omission placeholders of any kind may appear; all lists must be output completely item by item.
Unreplaced Templates Prohibited: All request/PoC templates must be replaced with real routes and real parameters, and must not retain ${var}. For host and session fields in request headers/Body, uniformly use {host}/{cookie}/{token} and other placeholders; unreplaced {{...}}。
Conclusions Only Prohibited: Each high-risk vulnerability must include "location evidence + data flow chain + exploitability analysis + verification PoC + remediation recommendations".
Non-Vulnerabilities Must Have Explanations: For suspicious patterns, conclusions and evidence such as "overridden by hardcoding/intercepted by validation/bypass ineffective/only Blind and cannot be verified" must be provided.

Output Integrity Verification (Mandatory)

After completion, the following checklist must be executed:

The route list and parameter list are "non-empty and have matching counts" (if split across multiple files, check the completeness of each separately)
The authentication mapping table covers all interfaces (or states "this interface is a static resource/non-entry/no route binding" but it must also be recorded in the table)
Every vulnerability in the vulnerability list has: ID, severity, location, data flow chain, exploitability, verification PoC, remediation recommendation
The report contains no unreplaced template placeholders (for example ${var} or unreplaced {{...}}）

Input

User-provided:

source_path: PHP project source path (can be a directory or repository root)
output_path: Output directory path (default {source_path}_audit）

Derived variables (used to ensure the outputs of each sub-skill can be aligned):

project_name: Extracted from the source_path directory name (basename)
timestamp: Generation timestamp, recommended format is YYYY_MM_DD_HH_mm(used for filename examples:2026_03_20_18_00）

Output directory structure (recommended as mandatory)

{output_path}/
└── {project_name}_代码审计_{timestamp}.md

Note:

The routes_{timestamp}.md、auth_mapping_{timestamp}.md、vuln_audit/sql_{timestamp}.md and other "file paths" appearing later only indicate the corresponding section content segments to be written into this overall report; they are not materialized as standalone files.
Similarly, "read file" is changed to "reference the corresponding section content already generated in this report".
Path unification with sub-skills: The route_mapping/routes_*.md and others appearing in each sub-skill are logically equivalent to the table abovelogically equivalent, see shared/IO_PATH_CONVENTION.md(pipeline merge vs. independent persistence).

Execution flow (staged pipeline: higher true positives)

False-negative suppression (mandatory, throughout all stages)

Silent discarding is prohibited：trace_status = UNRESOLVED, did not enter the SINK_SUSPECT heuristic list, or failed the trace contract,must notdisappear from the report. They must be listed one by one in the "Trace unclosed / risk pool pending evidence"(or an equivalent heading) of Stage 5 "Quality Report Section":route_id(or SINK_ONLY:…), known code location/snippet, type of missing evidence, recommended follow-up action (rerun trace, expand high_risk_routes, or perform the corresponding php-*-audit static deep review on that file).
Heuristics are not equal to safety: Stage 3's SINK_SUSPECT relies only on parameter name keywords,will inevitably misspaths where "the parameter name is ordinary but it reaches a sink"; Stage 2 (per-route data flow) + Stage 2.5 (global sink fallback) + the sink scans of each sub-skill must be used to complement each other.
Relationship between Stage 2.5 and Stage 4: All Stage 2.5 outputs are treated as ⚠️待验证（静态）, until a trace or sub-skill closes it with EVID_* ;must notbe deleted from the overall report because it did not pass trace-gate.
Balance between false positives and false negatives: When there is no complete trace,it is prohibitedto mark ✅已确认可利用(to prevent hallucination/false positives), but ⚠️待验证 or 🔍环境依赖 entries must be retained (to prevent false negatives).

Stage 1: Recon

Goal: Identify the foundational data for all "entry -> route -> parameter -> authentication chain".

Identify tech stack/entry form (mandatory)
- Laravel：routes/web.php、routes/api.php、app/Http/Controllers/、middleware
- Symfony：config/routes/*, Controller annotations/attributes
- Slim: routes defined in code ($app->get/post）
- WordPress：wp-admin/admin-post.php、admin-ajax.php, hook callbacks
- Native PHP: front controller,index.php、include chain,$_GET/$_POST dispatch
Enumerate routes/entry points (mandatory, omission prohibited)
- Extract from route configuration or dispatch logic: HTTP method, path/rule, corresponding handler (file/function/class method)
- For dynamic routes (such as {id}, regex routes, WordPress parameter routes), you must write out the "parsing rules and controllable parameter list"
Enumerate parameters (mandatory)
- Identify Source:$_GET/$_POST/$_REQUEST/$_FILES/$_COOKIE、php://input、getallheaders()
- Identify JSON:json_decode(file_get_contents('php://input'), true)
- Identify file:$_FILES['{file_field}'] field and filename source (name/tmp_name）
Identify authentication chain and session mechanism (mandatory)
- Session：session_start()、$_SESSION['key'], login state determination
- JWT：JWT::decode, signature verification logic,Authorization: Bearer
- Middlewares：Laravel middleware、Symfony event listener、Slim middleware
- Custom authentication:checkAuth()/requireLogin()/authorize() class functions
Generate authentication mapping (static mapping, do not rely on trace for now)
- Call:php-auth-audit
- Mode:STATIC_MAPPING(only generate auth_mapping_{timestamp}.md for P0/P1 route bucketing)
- Constraint: when route_tracer/ trace has not yet been generated, "missing trace contract evidence points" is allowed, but "authentication status grading + P0/P1 bucketing basis" must be output
Supply chain vulnerability scanning (known component CVE/Advisory)
- Call:php-vuln-scanner
- Output:vuln_report/{project_name}_composer_vuln_report_{timestamp}.md
Framework-specific audit (optional: call only when the corresponding framework is detected)
- Detection principle (mandatory): based on composer.json dependencies and typical directory/entry file characteristics, identify Laravel/Symfony/WordPress/CodeIgniter/Yii2
- Laravel: call php-laravel-audit, output framework_audit/laravel_{timestamp}.md
- Symfony: call php-symfony-audit, output framework_audit/symfony_{timestamp}.md
- WordPress: call php-wordpress-audit, output framework_audit/wordpress_{timestamp}.md
- CodeIgniter: call php-codeigniter-audit, output framework_audit/codeigniter_{timestamp}.md
- Yii2: call php-yii-audit, output framework_audit/yii_{timestamp}.md
- ThinkPHP: call php-thinkphp-audit, output framework_audit/thinkphp_{timestamp}.md

Phase 1 output:

routes_{timestamp}.md: complete route list (item by item)
params_{timestamp}.md: parameter source and type/structure for each route (item by item)
auth_audit/auth_mapping_{timestamp}.md: route authentication mapping (including P0/P1 bucketing basis)
vuln_report/{project_name}_composer_vuln_report_{timestamp}.md: component vulnerability list (used to infer affected routes)
framework_audit/*_{timestamp}.md: framework-specific audit report (produced only when the corresponding framework is detected in Phase 1)

Phase 2: Modeling

Goal: establish a "traceable version" of the Source → Sink data flow graph.

For each route, establish at least one "shortest path from entry parameter to sensitive Sink", and record:

Source parameter name/data structure field path (such as pageJson.orderBy PHP equivalent: array field path)
Intermediate variable name changes (assignment/concat/transform)
Branch conditions (if/switch/try/catch) and early returns (return/throw)
Sink type and call site (file/line number/function name)

Phase 2 output:

Route-level data flow chain evidence (recommended to embed in vuln_audit/* or create a separate dataflow_tracer/, keep it concise here: inlining into the vulnerability report is also fine)

Phase 2.5: Sink-only global scan fallback (improve recall, cover RCE and extended high-risk)

Goal: when route enumeration/trace-gate fails or evidence is insufficient, still be able to find high-risk points through "static Sink hit + local controllability backtracking + execution point confirmation", and uniformly downgrade to ⚠️待验证（静态证据），untilsupplementary evidence is provided in Phase 3/4.

Differences from Phase 3/4: Phase 2.5 performs a "broad-spectrum Sink preliminary screening" across all PHP source files, without depending on route completeness and trace completeness, and its output enters the downgraded candidate pool; Phase 3/4, after route + trace is completed, performs "high-confidence precise auditing" on Sinks that pass the trace-gate. The scan scopes of the two may overlap, but the execution timing, target precision, and output flow are different - the output of Phase 2.5 will not replace the confirmation results of Phase 4, and only serves as a fallback for missed findings.

Scan scope (no directory restriction)
- Starting from the source_path root directory, recursively traverse and cover all PHP source files in the project (for example *.php）。
- to reduce noise, by default vendor/ and cache directories may be excluded (if maximum recall is needed, the exclusion policy can be turned off).
Must-cover Sink set (minimum set)(to prevent missed detection of RCE/object injection)
- CMD：exec/system/shell_exec/passthru/proc_open/popen/pcntl_exec and backticks `cmd`
- EXPR：eval/assert as well as the deprecated but still common preg_replace(..., ..., .../e) risk points
- FILE (execution surface boundary):include/require poses a risk on "executable content/execution boundary" (read-only is not equal to RCE; execution semantics must be confirmed)
- DESER：unserialize(...) has a potential magic method execution chain on a controllable input chain (escalate only when static evidence is sufficient; otherwise leave pending verification)
Extended scan (strongly recommended, to prevent missed detection of SQL/SSRF/arbitrary read, etc.): on the business code directory, scan another round by shared/PHP_SINK_REFERENCE.md for SQL execution family（query/exec/prepare+ concatenation clues),SSRF family（curl_exec/file_get_contents($url) , etc.),arbitrary read family（file_get_contents/fopen+ path concatenation). Hits are written to the same sink_static_index_{timestamp}.md(or extended rce_sinks appendix), with entries marked "extended scan"; the conclusion remains ⚠️待验证 until trace or the corresponding php-sql-audit/php-ssrf-audit/php-file-read-audit is closed.
Local analysis of each hit point (must output)
- Location:file:line, function/statement, sink parameter expression (excerpt key fragments verbatim)
- Controllability backtracking: trace within the same file/adjacent call chain whether the sink parameter comes from request input (get/post/request()->param()、$_GET/$_POST/$_REQUEST、JSON php://input decoding results, header/cookie, etc.)
- Execution point confirmation: if it cannot be proven that the dangerous context will actually execute (for example, early return in a branch/exception skip/filtered out), the conclusion must be downgraded to ⚠️待验证
Output and summary rules (not dependent on route_id)
- Output to {output_path}/global_sink_fallback/：
  - rce_sinks_{timestamp}.md: static hit list of RCE/high-risk execution points (each entry includes location, controllability backtracking evidence, execution point confirmation, and reason for conclusion downgrade)
  - sink_static_index_{timestamp}.md: Static hit index (used for quality statistics and subsequent manual completion of trace)
- During Phase 5 aggregation: additionally reference in the "Vulnerability List Overview" of the "Quality Report Chapter" global_sink_fallback/rce_sinks_{timestamp}.md, and mark these items as "static evidence (non-trace-gate)".

Phase 3: Batched Tracing (Only When Trace Proves)

Goal: Through the "actual execution evidence" of php-route-tracer , upgrade vulnerability discovery from "keyword scanning" to "controllability and branch evidence driven", maximizing true positives.

Phase 3 must be executed in the following order:

Generate high-risk route set：
- Read auth_audit/auth_mapping_{timestamp}.md, extract P0 (❌ no authentication) and P1 (⚠️ authentication only or 🔓 risk routes that can be bypassed/privilege-escalated/IDOR)
- Read vuln_report/{project_name}_composer_vuln_report_{timestamp}.md, "inferentially map" component vulnerability trigger points related to parsing entry points/sensitive functionality to potentially affected routes, and annotate the "inference rationale"
- Supplement based on static parameter clues SINK_SUSPECT routes (does not rely on trace evidence points; trace-gate will perform hard threshold confirmation in Phase 4)
  - LDAP: parameter name/field name contains dn/baseDn/filter/searchFilter/ldap/filterString and other keywords (or their JSON field paths in route params)
  - EXPR: parameter name/field name contains expr/expression/condition/where/rule/eval and other keywords (or their JSON field paths in route params)
  - SQL: parameter name/field name contains sql/query/filter/orderBy/sort/limit/search and other keywords (or their JSON field paths in route params)
  - CMD: parameter name/field name contains cmd/command/exec/shell/run/path/filename and other keywords (or their JSON field paths in route params)
  - SSRF: parameter name/field name contains url/uri/target/host/port/protocol/path and other keywords (or their JSON field paths in route params)
  - FILE: parameter name/field name contains file/path/filename/download/view/document/template and other keywords (or their JSON field paths in route params)
  - UPLOAD: parameter name/field name contains upload/file/tmp_name/filename/multipart and other keywords (or their JSON field paths in route params)
  - WRITE: parameter name/field name contains write/put_contents/fwrite/fopen/rename/copy/truncate/error_log/dest/path/target/path and other keywords (or their JSON field paths in route params)
  - XSS: parameter name/field name contains content/body/comment/title/description/html and other keywords (or their JSON field paths in route params)
  - TPL: parameter name/field name contains template/view/engine/renderer/format/expr and other keywords (or their JSON field paths in route params)
  - XXE: parameter name/field name contains xml/doctype/dtd/xxe and other keywords (or their JSON field paths in route params)
  - DESER: parameter name/field name contains serialize/unserialize/payload/object/serialized and other keywords (or their JSON field paths in route params)
  - NOSQL: parameter name/field name contains filter/query/where/operator/op/regex/whereClause and other keywords (or their JSON field paths in route params)
  - REDIR: parameter name/field name contains next/return_to/redirect/target/url and other keywords (or their JSON field paths in route params)
  - CRLF: parameter name/field name contains header/cookie/location/set-cookie and other keywords (or their JSON field paths in the route params)
  - ARCHIVE: parameter names/field names contain zip/tar/phar/archive/entry/extractTo/unzip/untar and other keywords (or their JSON field paths in the route params)
- Synthesize route_id(mandatory): when entries come from CLI/cron/queue, WordPress hooks,include chains, stage 2.5 static sinks, etc.and have no HTTP route, a stable ID must be used (leaving it blank is prohibited), and on the same line write entry_file(relative source_path）、entry_symbol(function/method or global）、trace_from(where to start tracing toward the sink). Recommended:ENTRY_CLI:{脚本标识}、ENTRY_CRON:{任务名}、ENTRY_QUEUE:{消费者类或文件}、ENTRY_HOOK:{hook 名}、ENTRY_INCLUDE:{文件}:{符号}、SINK_ONLY:{序号}:{基名}:{行号}(may be cross-referenced with sink_static_index ).
- Output:cross_analysis/high_risk_routes_{timestamp}.md(including P0/P1/SINK_SUSPECT;each entry must have route_id(including the synthetic ID).php-route-tracer Use route_id to identify the task, and the tracing starting point is determined by entry_file+entry_symbol+trace_from ; the ID is not required to have the form of a URI.)
Generate a batched tracing plan：
- Read high_risk_routes_{timestamp}.md
- Batching parameterization (mandatory): order P0 → P1 → SINK_SUSPECT。trace_batch_max_size default 10, may be adjusted per project within 5–30 ; the plan must statethe rationale for the selection(e.g.: routes in the same module may be merged into a larger batch; if the call chain is deep, spans many files, has a wide parameter surface, or the context budget is tight, reduce the batch size).
- trace_batch_plan_{timestamp}.md Each batchmust contain:batch_id, the trace_batch_max_size、rationale for the selectionadopted by this batch (1–3 sentences), and this batch's route_id ordered list.
- Output:cross_analysis/trace_batch_plan_{timestamp}.md
Batch invocation tracer(required):
- Invoke for each batch of routes php-route-tracer
- Output:route_tracer/{route_id}/trace_{timestamp}.md
Trigger conditions (hard thresholds)：
- Only when a certain type of sink has a "real sink execution point" in the trace, and the trace contract validation passes, and the corresponding parameter is not "uncontrollable/no actual use (overridden by hardcoding)" in the trace's controllability matrix, is it permitted to proceed to stage 4 and trigger the corresponding php-*-audit
Trace contract validation (required)：
- Each trace file must contain the following sections/headers (field names must be identical and must not be renamed):
  - ## 7) Sink Summary
  - ## 5) 参数可控性矩阵
  - ## 6) Sink 定位
  - ## 8) Trace 完整性声明
  - ## 9) Sink Evidence Type Checklist
- If trace contract validation fails:
  - The trace of that route must be marked as PARTIAL or UNRESOLVED
  - For all vulnerabilities supported by that trace, the status must be downgraded to ⚠️待验证, and ✅已确认可利用。

For the complete provisions on sink type handles, dangerous patterns, and mandatory validation, see this repository's shared/PHP_SINK_REFERENCE.md(sections 3.1–3.16 and LDAP/EXPR). When stage 3/4 determines based on the trace whether to trigger the corresponding php-*-audit , that file shall govern.

Stage 3 output:

cross_analysis/high_risk_routes_{timestamp}.md
cross_analysis/trace_batch_plan_{timestamp}.md
route_tracer/ Under each traced route's trace_{timestamp}.md(including the parameter controllability table and branch path evidence)

Stage 4: Sink audit execution (Only When Trace Proves)

Steps:

From route_tracer/ Filter the vulnerability categories requiring 'trace-gate' and the 'actual parameter usage status' from the trace (must be based on the trace controllability matrix).
- trace-gate categories: SQL/NOSQL/CMD/SSRF/FILE/UPLOAD/WRITE/ARCHIVE/XSS/REDIR/CRLF/XXE/DESER/TPL/LDAP/EXPR/AUTH/CSRF/SESS
- Non-trace-gate categories: CFG/CRYPTO/LOGIC/LOG (the corresponding skill can be invoked directly based on static scanning and code configuration evidence,not using trace ## 9) … CFG as thesole threshold). Note:php-route-tracer Although the checklist contains a CFG row, it serves only asenhancing evidence；php-config-audit etc. must still be in Phase 4 executed unconditionally as planned(unless the coverage matrix has already marked them as not applicable with negative evidence).
Invoke the corresponding sub-audit skill only for the hit categories; and satisfy the following 'evidence source' rules (inferring from keywords alone is prohibited):
- If the category belongs to trace-gate: must cite item by item the php-route-tracer 's ## 9) Sink Evidence Type Checklist corresponding row (FILE/UPLOAD/WRITE/ARCHIVE/SSRF/SQL/NOSQL/CMD/XSS/REDIR/CRLF/XXE/DESER/TPL/LDAP/EXPR/AUTH/CSRF/SESS) evidence points as the audit basis (evidence point IDs are required to be identical as-is)
- If the category is AUTH: invoke php-auth-audit 's TRACE_AUDIT pattern (must cite trace evidence point IDs)
For each suspected vulnerability, the 'exploitability preconditions' must be output:

Authentication requirement: ✅Not required / ⚠️Login required / ❌Not exploitable threshold
Input controllability: ✅Fully controllable / ⚠️Conditionally controllable / ❌Not controllable (hardcoded overwrite)
Trigger conditions: branch conditions/exception paths/environment dependencies (database type, network reachability)

Trace completeness fallback rules (mandatory)：
- If trace_status = PARTIAL: can only enter ⚠️待验证 mode (must not directly give ✅已确认可利用）
- If trace_status = UNRESOLVED:silent omission is prohibited— must not be written as 'no risk' or disappear from the report. Must in the overall report 'Trace Unclosed / Pending Evidence Risk Pool' , for that route_id list a separate entry:已知片段(from the reachable part of the trace),缺失证据、建议下一步(supplement trace / include in SINK_ONLY static deep audit / invoke the corresponding php-*-audit). If this route can be correlated with a Phase 2.5 static hit, a cross-reference must be written.
File system operation audit (non-trace-gate, static evidence-driven)：
- Invoke:php-filesystem-audit
- Output:vuln_audit/fs_{timestamp}.md
- Decision rule: allowed to directly output based on the 'file system operation evidence chain + path control source + TOCTOU/link bypass explanation' located from source code ✅/⚠️/❌/🔍, not using php-route-tracer 's evidence contract fields as a prerequisite hard threshold

and finally give:

Status: ✅Confirmed / ⚠️Pending verification / ❌Not exploitable / 🔍Environment-dependent
Severity level and CVSS mapping (according to the formula above)

Phase 5: Summary Report (Report)

Generate a 'Quality Report Section' in the overall report, including:

Sub-skill / audit surface coverage matrix: Same structure as the above "Sub-audit Coverage Matrix (Mandatory)", placed near the front of the quality report; it must be consistent with the actual execution status of Phase 4 and must not contradict it.
Risk Statistics Table (🔴/🟠/🟡/🔵 counts and CVSS ranges)
Vulnerability List Overview (cite the corresponding vulnerability detail paragraph in this report for each item)
"Trace Unclosed / Evidence-Pending Risk Pool"(Mandatory): summarize trace_status ∈ {PARTIAL, UNRESOLVED} of route_id, entries in Phase 2.5 sink_static_index that have not yet been closed by trace, and "Extended Scan" hits; listed in parallel with the "Vulnerability List Overview",forbiddento delete records due to insufficient evidence (unclosed ≠ no risk).
Coverage: route coverage, authentication coverage, Sink coverage, key branch coverage (use "completed/to be supplemented" rather than omitting; recommended thresholds: route coverage and Sink coverage >= 90%)
Framework-specific audit summary: if framework_audit/*.mdexists, its risks need to be mapped to unified type codes (AUTH/CSRF/TPL/XSS/SQL/LOGIC/CFG/SESS/SSRF/…), with counts and the highest severity level tallied, and the summary must note "which framework_audit report files the framework risks come from"

Framework Audit Exemption Note: Framework-specific audits (Laravel/Symfony/WordPress/CodeIgniter/Yii2/ThinkPHP) are "static configuration/pattern matching" audits, and the risks they find do not need to go through php-route-tracer 's trace-gate or ## 9) Sink Evidence Type Checklist 's evidence verification. Framework audit results can simply be graded according to their own rules and mapped to unified type codes.
Evidence Completeness Score: for all trace-gate sink types (FILE/UPLOAD/WRITE/ARCHIVE/SSRF/SQL/NOSQL/CMD/XSS/REDIR/CRLF/XXE/DESER/TPL/LDAP/EXPR/AUTH/CSRF/SESS), count according to the evidence point ID set defined in shared/EVIDENCE_POINT_IDS.md :覆盖率% = 已满足证据点数 / 该类型所需证据点总数 × 100%; and list in the table the missing evidence point IDs (must be verbatim identical) and the reasons for missing (e.g., trace_status=PARTIAL/UNRESOLVED, evidence point location failure, uncontrollable parameters, etc.).

Phase 5.1: Exploit Chain Aggregation (Mandatory)

Invoke:php-exploit-chain-audit
After the "Vulnerability List Overview" in the "Quality Report Chapter", add an "Exploit Chain Aggregation Chapter": cite the chain overview table and the shortest exploit chains from the exploit chain aggregation report (only cite, do not repeat content).

Vulnerability Detail Template (Mandatory Use)

Each vulnerability must follow the structure below (written into the vulnerability detail paragraphs of this overall report):

### [{等级前缀}-{类型代码}-{序号}] {风险标题}

| 项目 | 信息 |
|------|------|
| 严重等级 | {🔴/🟠/🟡/🔵} (CVSS {score}) |
| 可达性 (R) | {0-3} - {理由} |
| 影响范围 (I) | {0-3} - {理由} |
| 利用复杂度 (C) | {0-3} - {理由} |
| 可利用性 | ✅ 已确认 / ⚠️ 待验证 / ❌ 不可利用 / 🔍 环境依赖 |
| 位置 | {文件路径}:{行号} ({函数/方法}) |

#### 数据流链（Source → Sink）

(Write out assignment/passing/concatenation/validation/branch line by line by route; omission is forbidden)

Exploitable Preconditions

Authentication requirement: {none/login required/specific permission required}
Input controllability: {fully controllable/conditionally controllable/not controllable}
Trigger condition: {branch/exception/environment dependency}

Verification PoC (executable request must be provided)

{HTTP Method} {完整路径与查询/Body} HTTP/1.1
Host: {host}
{必要 Header/Session/JWT/Cookie}

{Payload}

Recommended Fix

Focus on "code replacement suggestions" (provide key points for secure coding)
Provide the search statement (in bash/rg form) for "how to search the code for whether the fix was missed"


## 说明文档（审计 READMEs）
必须在本次总报告内生成以下附录章节：
- 如何识别 PHP 路由与参数
- 如何识别会话/JWT 并审计鉴权链
- 如何结合 `shared/PHP_SINK_REFERENCE.md` 做按类型的 Sink 挖掘与 trace-gate 对齐

## 自检与质量保证（强制）
在标记完成前，必须回答并自检：
- [ ] 「子 skill / 审计面覆盖矩阵」是否已对对照表**每一行**给出已执行/不适用/已延期，且不适用与已延期均附触发依据或否定证据？
- [ ] 我是否按 `shared/PHP_SINK_REFERENCE.md` 与 trace 结果覆盖了常见高危类别（SQL/NOSQL/CMD/SSRF/XSS/FILE/UPLOAD/WRITE/ARCHIVE/XXE/DESER/TPL/AUTH/CSRF/REDIR/CRLF/SESS/CRYPTO/CFG/LOG/FS）？
- [ ] 我是否覆盖 LDAP/EXPR（或矩阵中「不适用」已附否定证据）？
- [ ] 每条漏洞是否都有数据流链与可利用前置条件？
- [ ] 是否没有任何省略写法？
- [ ] 是否没有任何未替换的模板占位符？
- [ ] **「Trace 未闭合 / 待补证风险池」**是否已列出所有 `PARTIAL/UNRESOLVED` 及 2.5 未闭合静态命中，且与漏洞列表无矛盾？

## 子 Skill 对照表（能力清单 + 矩阵对齐）
下表为**必须出现在「子 skill / 审计面覆盖矩阵」中的行清单**。阶段 3/4 按 trace-gate 与静态证据触发对应 skill；**未执行**的行须在矩阵中标记「不适用」或「已延期」并满足矩阵列要求（禁止空行、禁止无理由跳过）。

1. 路由/参数：`php-route-mapper`
2. 鉴权：`php-auth-audit`
3. 深度追踪：`php-route-tracer`（用于任何需要可控性/分支证据的场景）
4. 组件漏洞（供应链）：`php-vuln-scanner`

5. 利用链聚合：`php-exploit-chain-audit`（在阶段 5.1 强制调用）

6. 文件系统操作审计：`php-filesystem-audit`（在阶段 4 以静态证据驱动执行）

按漏洞类别调用：
- SQL 注入：`php-sql-audit`
- NoSQL 注入：`php-nosql-audit`
- 命令注入：`php-cmd-audit`
- SSRF：`php-ssrf-audit`
- XSS：`php-xss-audit`
- 模板注入/SSTI：`php-tpl-audit`
- LDAP 注入：`php-ldap-audit`
- 表达式注入（非模板）：`php-expr-audit`
- 任意文件读取/路径穿越：`php-file-read-audit`
- 文件上传：`php-file-upload-audit`
- 任意文件写入：`php-file-write-audit`
- 归档解压路径穿越/Zip Slip：`php-archive-extract-audit`
- XXE：`php-xxe-audit`
- 反序列化/对象注入：`php-deser-audit`
- 认证/鉴权绕过/越权/IDOR：`php-auth-audit`（与鉴权状态、资源归属一起落入汇总）
- CSRF：`php-csrf-audit`
- 开放重定向：`php-open-redirect-audit`
- CRLF/响应分割：`php-crlf-audit`
- 会话与 Cookie 安全：`php-session-cookie-audit`
- 加密与密钥安全：`php-crypto-audit`
- 安全配置（CORS/错误暴露/安全头/危险开关）：`php-config-audit`
- 业务逻辑漏洞（Mass Assignment/竞态/状态机/流程绕过）：`php-logic-audit`
- 安全日志与监控：`php-logging-audit`