This skill is the core component of Phase 5 of the audit pipeline. After each classified audit skill produces an independent vulnerability list, the feasibility of exploiting combinations of multiple vulnerabilities is assessed here, chaining single-point vulnerabilities into a complete attack path.
Prerequisites for chain assembly
- Each sub-audit (P4 phase) has been completed, and the vulnerability list has been produced
- Each "confirmed" vulnerability is accompanied by complete EVID_* evidence (Source→Sink path, controllable parameters, filtering status)
- Vulnerabilities lacking EVID evidence do not participate in chain assembly and can only be marked as "potential chain nodes"
Common exploitation chain patterns
| # | Entry vulnerability | Intermediate pivot | Final effect | Severity |
|---|---|---|---|---|
| 1 | File write (arbitrary content) | include/require Path controllable |
RCE | Critical |
| 2 | SQL injection | INTO OUTFILE / DUMPFILE |
Webshell landing | Critical |
| 3 | Deserialization entry | POP Gadget chain | Arbitrary operation (file write/command execution) | Critical |
| 4 | SSRF | Internal unauthenticated service (Redis/FastCGI) | RCE / data leakage | High-Critical |
| 5 | Information disclosure (key/salt) | Forged signature / decrypted token | Authentication bypass | High |
| 6 | XSS (stored) | CSRF Token theft | Administrator operation hijacking | High |
Chain assembly process
- Collect confirmed vulnerabilities — Aggregate all sub-audit outputs, including only entries with complete EVID evidence. Label each by vulnerability type with its "output capability" (can write files, can send requests, can leak data, can execute code)
- Build vulnerability relationship graph — Determine whether each vulnerability's output can serve as another vulnerability's input (file write path→file inclusion path, information disclosure content→authentication forgery key, SSRF reachable scope→internal service address)
- Find Source→Sink chain pairs — Search the relationship graph for the shortest path from a low-privilege entry to a high-impact Sink, prioritizing unauthenticated entry points
- Verify chain preconditions — Confirm step by step: authentication requirements (privilege gap), network reachability (target network segment), timing dependencies (file cleanup/Session expiration), environmental constraints (
open_basedir/disable_functions/secure_file_priv） - Calculate chain severity —
Score = R * 0.40 + I * 0.35 + C * 0.25(consistent with pipeline), the chain takes the R/I/C values of its weakest link; if any step is unreachable, the entire chain does not hold
Detailed conditions for each chain pattern
File write + include → RCE: The write path must be under include_path or the Web root directory; the written content must contain a controllable PHP code snippet;include/require 's path parameter must be controllable or predictable (e.g., a fixed log path).
SQL injection + INTO OUTFILE → Webshell: The database user must have the FILE privilege;secure_file_priv must be empty or contain the Web directory; the write path must be directly accessible via the Web; the target file must not already exist (OUTFILE not covered).
Deserialization + POP chain → arbitrary operations: user-controllable data reaches the unserialize/phar:// trigger point; a usable Gadget class exists in the project or Composer dependencies;__destruct/__wakeup → the call chain to the dangerous Sink is fully reachable.
SSRF + internal services → RCE/data leakage: gopher:// or http:// protocol is available (not restricted by CURLOPT_PROTOCOLS ); the target internal service has no authentication (Redis without a password, FastCGI without access control); the response can be echoed back or supports blind exploitation (DNS/delay).
Information leakage + forged signature → authentication bypass: the leaked key is the actual signing key (not a test value); the signing algorithm is known and can be reproduced locally; the forged Token/Cookie is within its validity period and is not blocked by a revocation mechanism.
XSS + CSRF → admin action hijacking: the XSS is stored or can be triggered persistently; the target admin page has no separate CSRF Token or the Token can be read via XSS; critical operations (adding an admin/modifying configuration) have no secondary confirmation.
Composer dependency audit
- Parse
composer.lockto obtain the exact version numbers of all direct + indirect dependencies - Compare against Packagist Security Advisories and the CVE databases (NVD/GitHub Advisory)
- Focus on known vulnerabilities in indirect dependencies (packages that
require's packages depend on) — developers often overlook these - Tool assistance:
composer audit（Composer 2.4+）、local-php-security-checker - Dependency CVEs found are also incorporated into the exploit chain relationship graph to assess whether they can be chained with business logic vulnerabilities
Reporting requirements when a chain is not feasible
When a chain cannot be established, the break point must be clearly stated:
- Which specific step's precondition is not satisfied (e.g.,
secure_file_privrestricts the write path) - Whether that condition could hold in other environments/configurations (marked as "environment-dependent")
- Whether an alternative path exists to bypass that break point
Detection checklist
- All confirmed vulnerabilities have been summarized, and EVID evidence completeness has been reviewed
- The vulnerability relationship graph has been built, and output→input correspondences have been annotated
- The preconditions of each feasible chain have been verified step by step
- Environmental constraints (
open_basedir/disable_functions/secure_file_priv) have been confirmed - Chain severity has been calculated based on the weakest link, and the scoring is consistent with the pipeline
- Infeasible chains have been marked with their break points and reasons
- Composer dependency CVEs have been scanned and included in the chain assessment
- The chain exploitation path has been fully verified at the source code level