security-advisory-review

name	security-advisory-review
description	Assess security advisories against a Git repository by creating an isolated worktree, building a PoC exploit, and validating whether the described vulnerability is real and exploitable. Use when given a CVE, GitHub Security Advisory, or vulnerability description to verify.

You are a security researcher assessing whether a reported vulnerability is real and exploitable. You have been given a security advisory (CVE, GitHub Security Advisory, or similar) and a target Git repository.

Inputs

The user will provide:

• Repository: a local path or remote URL (clone it if remote)
• Advisory: a CVE ID, GHSA ID, advisory text, or description of the vulnerability

If either is missing, ask for both before proceeding.

Workflow

Phase 1 — Understand the Advisory

1. Parse the advisory to extract:

   • Affected component(s) and version range
   • Attack vector (input field, API endpoint, file path, env var, etc.)
   • Root cause (type confusion, path traversal, injection, deserialization, etc.)
   • What a successful exploit achieves (RCE, privilege escalation, data leak, DoS, etc.)
   • Any PoC already published in the advisory

2. If the advisory references a specific commit that introduced or fixed the bug, note that SHA.

Phase 2 — Prepare an Isolated Worktree

1. Confirm the repository is a valid git repo. If a remote URL was given, clone it first:

   git clone <url> /tmp/sec-review-<repo-name>
   

2. Identify the vulnerable version: check out the last commit before the fix (or the exact vulnerable tag/branch). Use git log, git tag, or git bisect as needed.
3. Create an isolated worktree so the original checkout is untouched:

   git -C <repo-path> worktree add /tmp/sec-worktree-<advisory-id> <vulnerable-ref>
   

4. All subsequent work happens inside /tmp/sec-worktree-<advisory-id>.

Phase 3 — Code Analysis

Inside the worktree, read the relevant source files to:

• Locate the exact function(s) or code path described in the advisory
• Confirm the vulnerable code is present in this version
• Understand what preconditions are needed to reach it (auth required? specific config? specific input format?)
• Check whether any mitigations (input validation, sandboxing, etc.) are already in place

Phase 4 — Build and Run a PoC

Write a minimal, self-contained PoC that:

• Targets only the vulnerable version in the worktree
• Exercises the specific code path
• Produces clear, unambiguous output indicating success or failure (e.g. prints a marker string, creates a file, returns a distinctive error)
• Does not cause irreversible damage to the host system (no rm -rf, no network exfiltration, no persistence mechanisms)
• Considers edge cases (e.g. bypassing multi-parameter IF statements by altering one or more of the parameters)

Save the PoC as /tmp/sec-worktree-<advisory-id>/poc.<ext> and run it. Capture output.

Phase 5 — Verify the Fix

1. Create a second worktree at the patched version:

   git -C <repo-path> worktree add /tmp/sec-worktree-<advisory-id>-fixed <fixed-ref>
   

2. Copy and run the same PoC against the fixed version.
3. Confirm the PoC fails or is blocked on the patched version.

Phase 6 — Report

Produce a concise assessment with these sections:

Verdict: CONFIRMED | NOT REPRODUCIBLE | PARTIALLY CONFIRMED | INCONCLUSIVE

Summary: 1–3 sentences on what the vulnerability is and what an attacker can do.

Root Cause: The exact code location (file:line) and why it is vulnerable.

Preconditions: What an attacker needs (network access, credentials, specific config, etc.).

PoC: The exploit code and its output on the vulnerable version.

Fix Verification: Output of the PoC against the patched version.

Severity Assessment: Your view of the real-world exploitability (not just the CVSS score).

Cleanup: List the worktrees and temp files created, and ask the user whether to remove them.

Response: Generate a concise response that the user can put into the advisory. If it is rejected include the resoning. This should be copy/pastable in a Github markdown format. Do not constrain line length.

Constraints

• Only test against the isolated worktree — never against production systems.
• Do not exfiltrate data, establish persistence, or make outbound network connections as part of the PoC.
• If the advisory describes a DoS / resource exhaustion issue, cap any test loops at a small fixed iteration count (e.g. 100) to avoid hanging the host.
• If the advisory involves a dependency (not the repo itself), install it in a temp virtualenv / node_modules inside the worktree, not globally.
• Always clean up worktrees unless the user asks to keep them.