chain-info-to-exploit

Signals

• asset-map/nmap/httpx fingerprinted a service version with a known public CVE.
• An error message, stack trace, debug endpoint, or verbose response leaked an internal file path, framework version, or directory structure.
• A .git directory, backup file, build artifact, or exposed source repository is reachable, potentially containing hardcoded credentials or API keys.

Prerequisites

• The disclosure finding itself already confirmed (the leak is real and reproducible).
• For version/CVE chains: the specific CVE identified with its public advisory/PoC reference.

Methodology

1. Version leak + CVE.
   • Confirm the exact version string from the service directly (banner, headers, error page), not from a guess based on general fingerprinting.
   • Look up CVEs matching that exact version/build (searchsploit, vendor advisories, NVD). Note the CVE ID, affected version range, and whether the observed version falls inside it precisely (off-by-one version confusion is common and invalidates the match).
   • Per project anti-fabrication rule: a version/CVE match alone is not a finding. You must attempt the actual trigger (the public PoC, or your own re-derivation of it) against the target and observe a real effect. If the trigger can't be safely attempted (destructive PoC, no safe variant), report as "Inferred" with the reasoning explicit, and ask the operator whether a controlled, low-impact trigger attempt is authorized.
2. Internal path disclosure + LFI.
   • From the leaked path (stack trace, error message, source map, debug page), identify the real filesystem layout and any parameter that might accept a path and return file contents.
   • Test LFI with a benign, well-known file read (e.g. an app config file, not /etc/passwd as the headline claim — reading app-internal files is usually more impactful and more clearly in-scope than reading OS files) with path traversal/null-byte/wrapper variations as needed for the specific stack.
   • If the include sink also executes (not just reads) the included file — e.g. PHP include() of an attacker-reachable path — hand off to chain-web-to-rce for the execution leg rather than reporting LFI and RCE as unrelated findings.
3. Source code leak + hardcoded credentials.
   • From an exposed .git directory, backup file (.bak, .old, ~), or build artifact, reconstruct the source (e.g. git-dumper-equivalent extraction of a reachable .git, or direct download of the artifact).
   • Scan the recovered source with gitleaks/truffleHog and manual grep for API keys, database credentials, signing secrets, and cloud credentials.
   • For every credential found, test (minimally, non-destructively, within RoE) whether it is live — an unused/rotated/placeholder credential found in source is a lower-severity finding ("secret hygiene") than a live, currently-valid credential granting real access. Never assume liveness from presence alone.

Validation gate

• CVE-based claims require either a successful trigger observed against the target, or an explicit "Inferred" label with the version-match reasoning and an explicit note that exploitation wasn't attempted (and why) — never silently upgrade to "Demonstrated."
• LFI claims require an actual file content returned in the response, with the request/ response pair preserved as evidence.
• Credential-liveness claims require a specific, minimal-impact test (e.g. an authenticated read-only API call) with its result recorded — "found in source" and "confirmed live" are reported as distinct facts, never merged.

Gotchas

• Banner/version strings are sometimes deliberately spoofed or left stale after a patch (vendor backports a fix without bumping the version) — a matching version string is a strong lead, not proof; the trigger attempt is what actually proves it.
• Verbose error pages in a properly configured WAF/CDN setup may differ between what you see directly and what a real attacker would see at the edge — note which layer you tested through.
• A .git exposure might be partial (object files purged, shallow clone) — confirm you actually reconstructed usable source before claiming full source disclosure.
• Credentials found in source are frequently for a different environment (dev/staging) than the one currently in scope — confirm which environment a credential actually authenticates against before claiming it grants access to the in-scope target.
• Testing a found credential against a live system is itself a sensitive action — confirm it falls within RoE and, if there's any ambiguity about which system it authenticates to, treat that ambiguity as a reason to pause and ask, not to proceed.