pentest-cve-reverse-engineer

name	pentest-cve-reverse-engineer
description	Manual vulnerability research skill for finding advisories, downloading affected and fixed artifacts, diffing patches, confirming root cause, and writing reliable reports across products and technologies.

Vulnerability Reversal Report

Mission

Turn a public vulnerability lead into an evidence-backed report.

Use a simple path:

1. identify the advisory and product
2. download the affected and fixed artifacts
3. compare the change
4. trace source to sink or condition to impact
5. document what is proven, inferred, and still unknown

Intake

Normalize the request into the smallest useful target.

Capture:

• identifier: CVE, GHSA, vendor advisory, bug ID, or release note
• product, component, package, plugin, appliance, library, or service
• affected version range
• fixed version or patch reference
• vulnerability class and CWE when available
• attacker position and privileges
• impact claim
• source URLs
• local artifact paths

Use the strongest anchor first: exact advisory, exact version pair, exact patch, exact package, then broader product search.

Source Order

Prefer sources that are closest to the code and release process:

1. vendor advisory, security bulletin, or release note
2. upstream patch commit, tag, changelog, or diff
3. official package registry or download archive
4. public vulnerability databases
5. third-party writeups as supporting context

Record disagreements instead of smoothing them over.

Workflow

1. Find

Collect the facts needed to reproduce the research:

• identifier and title
• affected and fixed versions
• affected component or feature
• vulnerable entry point
• required privileges
• claimed impact
• references

Rank leads by evidence quality, exploitability, business impact, and availability of affected/fixed artifacts.

2. Download

Fetch the minimum artifact set needed to prove the change:

• one affected version
• one fixed version
• optional intermediate version when the boundary is unclear

Use official sources where possible:

• source tags or release archives
• package registry tarballs
• vendor binaries or firmware
• container images
• patch files or commits

Verify artifacts with version metadata, checksums, signatures, manifest files, changelogs, or package headers when available.

3. Compare

Diff the vulnerable and fixed versions.

Useful commands:

diff -ruN old new
git diff --no-index -- old new
rg -n "CVE|security|sanitize|escape|auth|permission|nonce|token|sql|exec|deserialize|upload|path|redirect" old new

Focus on changes that affect trust boundaries:

• authentication and authorization
• input validation and parsing
• escaping, encoding, and sanitization
• SQL, command, template, or deserialization sinks
• file upload, path handling, and archive extraction
• SSRF, redirects, callbacks, and outbound requests
• crypto, token, session, and signature checks
• dependency bumps with security relevance

4. Reverse

Build a short evidence chain:

• source or trigger
• attacker-controlled input
• missing or weak control
• vulnerable sink or state transition
• patch behavior
• practical impact

Mark each claim:

• Confirmed: visible in source, diff, runtime, or official advisory
• Inferred: likely from patch context but not directly proven
• Unknown: needs dynamic validation, missing artifact, or vendor-only detail

5. Validate

Use a controlled lab or static proof that matches the evidence.

Good validation outputs:

• minimal request shape
• function call or unit-level trigger
• config or role prerequisite
• before/after behavior
• error message, log, response, or diff-backed proof

Keep proof steps bounded to verification of the disclosed issue.

6. Report

Write the result so another analyst can audit it quickly.

Recommended files:

<identifier-or-product>/
  README.md
  report.md
  poc.md
  changes.diff
  references.md

Use only the files that add value for the case.

Report Template

# <Identifier> - <Product> <Vulnerability Class>

## Summary
<One paragraph with product, affected versions, condition, impact, and fix.>

## Identification
- Identifier:
- Product:
- Component:
- Affected versions:
- Fixed version:
- Vulnerability class:
- CWE:
- Attacker position:
- Confidence:

## Evidence
- Advisory:
- Fixed release or patch:
- Affected artifact:
- Fixed artifact:

## Root Cause
<Explain source to sink or condition to impact. Name files, functions, routes, parameters, and checks.>

## Patch Analysis
<Explain what changed and why it removes or reduces the issue.>

## Proof
<Minimal lab-safe request, call, setup, or static proof. Include prerequisites.>

## Impact
<Practical outcome and limits.>

## Remediation
<Upgrade, patch, config mitigation, detection, or compensating control.>

## Gaps
<Unknowns, unverified assumptions, source disagreements, or missing artifacts.>

Reliability Rules

• Keep the report anchored to artifacts and URLs.
• Quote file paths, functions, parameters, versions, and hashes exactly.
• Prefer a narrow confirmed finding over a broad uncertain claim.
• Preserve uncertainty explicitly.
• Keep payloads minimal and lab-scoped.
• Record the exact commands used when they matter to reproducibility.