---

name: vuln-repro description: >- End-to-end methodology for reproducing AND patching publicly disclosed, already-fixed vulnerabilities: sourcing the advisory and the fix commit, reading the patch diff, rebuilding a pinned offline lab, building a vulnerable-vs-patched contrast harness with proper controls, minimizing the trigger, designing and validating the fix, and writing it up as a blog post or whitepaper. Use this skill whenever the user wants to reproduce, demonstrate, understand, teach, or write about a known vulnerability or security incident: "reproduce this CVE", "build a repro for", "how did EchoLeak / Log4Shell / the postmark-mcp package actually work", "show me how this exploit worked", "write a blog post about this vulnerability", "set up a lab for CVE-XXXX", "pull the NVD/CVE/OSV details", or "make a PoC I can publish". Use it just as eagerly for the patching half: "how should this be fixed", "is this patch correct", "what would have caught this", "review this security fix", "write a regression test for this CVE", "how do I backport this", or "what's the right fix for this bug class" - even when the user never says the word "reproduce". Reach for it on vague asks like "help me understand this security advisory", "I want to write about this incident", or "can we test whether we were vulnerable" when a disclosed vulnerability is in play. This skill only handles ALREADY-PATCHED, publicly disclosed issues and refuses zero-day discovery, live targets, and weaponization.

vuln-repro

Reproduce a disclosed vulnerability faithfully, explain the fix that closed it, and publish the result. The output is a controlled experiment plus an engineering analysis, not a demo.

The hard line, read this first

This skill reproduces the past. It does not discover the new. Everything below depends on that distinction holding, and it is what keeps the work legal and publishable.

• Only patched or withdrawn issues. A fix version, a patch commit, or a withdrawal notice. "Reported to the vendor" and "advisory published" are not patched. No fix, no repro. Stop and say so.
• Use the last public vulnerable version, pulled from the ordinary public channel. You are studying something already on the internet.
• Never develop new exploitation. No fuzzing for new bugs, no chaining, no variant hunting against unfixed code, no bypassing a control the vendor has not fixed. If faithful reproduction would require inventing an undisclosed step, leave that step out and write down that you did.
• Offline, loopback, synthetic. No third-party host, no real credential, no real target or recipient, no persistence, no exfiltration. Success means a local marker appears or a policy decision is logged, never that code ran on someone's machine or data left the lab.

When a request crosses the line, decline that specific part in one sentence, say why (it would be new offensive work), and offer the safe version. Do not moralize; just redraw the boundary and keep building.

One boundary that confuses people: varying your own payload against your own patched build to check the fix is not payload-shaped is validation, and it is in scope. Hunting variants against the vendor's unfixed code is discovery, and it is not. If validation surfaces an unpatched sibling, that is a new finding: it goes to the vendor privately, never into the blog post.

What a reproduction actually is

A repro is a falsifiable claim, not a screenshot:

Under environment E, input I drives system S at version V-vuln into state X. The same I against V-fixed does not reach X, because of change C.

Everything below exists to make E, I, V, X, and C precise enough that a stranger re-runs you and gets the same answer. A repro that shows X happening but cannot explain C is a test case. One that explains C is a paper people cite.

Workflow

Work these in order. Steps 1-3 are cheap and kill bad targets early; skipping them is why most repro attempts die in step 6 with an unexplainable failure.

1. Gate: is it public and patched?

Fill this table before writing any code. An unknown cell means not ready.

| Fact | Acceptable evidence | |---|---| | Disclosure | Vendor advisory, GitHub/GitLab/MSRC advisory, researcher write-up | | Fix | Fixed version, patch commit SHA, or withdrawal notice | | Last vulnerable version | The public release immediately before the fix |

Pull the machine-readable half in one shot:

python3 scripts/triage.py CVE-2025-32711

That queries NVD, CVE.org, and OSV, prints a merged view, and states a patched verdict. Individual fetchers (fetch_nvd.py, fetch_cve.py, fetch_osv.py, check_patched.py) exist when you want one source. All are read-only against public vulnerability databases.

If the verdict is UNCONFIRMED, verify against the vendor by hand. Treat that as a red light, not a yellow one.

For where to look beyond the APIs, and how much to trust each source, read references/sourcing.md. That file is the answer to "where should I be looking?" and it is worth reading in full the first few times.

2. Decide whether the target is worth it

Not every CVE deserves a week. Score on: is it truly patched; is the mechanism published in enough detail to reproduce without inventing steps; can you build the vulnerable environment legally and cheaply; does it teach a class of bug rather than an instance; and is someone else's write-up already definitive.

The best target is usually a small patch with a large consequence. A three-line diff that turns full compromise into a clean refusal is the most instructive object in security.

A SaaS backend patched server-side (most AI-agent CVEs) cannot be reproduced at all. You can only model it. That is a legitimate artifact, but it must be labeled a model in the title and the first paragraph. Claiming to reproduce something you modeled is the fastest way to lose a technical audience.

3. Read the patch before you write the exploit

This inverts the amateur order and is the single biggest quality difference between a good repro and a bad one. The diff gives you the entry point, the precondition, the oracle, and the bug class for free.

git log --oneline v1.2.3..v1.2.4          # what changed between vuln and fix
git show <fix-sha>                         # the fix alone
git log --all --grep='CVE-2024' --oneline  # projects often reference the CVE
git log -S'vulnerable_function' --oneline  # finds silent fixes with no CVE label

Two things to hunt specifically. The silent fix: many projects patch under a message like "improve input handling"; git log -S on the vulnerable identifier finds these. The incomplete fix: check whether a follow-up commit touched the same function weeks later, because that story is usually the best part of the write-up.

Reason from the diff, not from the CVE prose. CVE descriptions are written by people summarizing at a distance and are regularly wrong about the mechanism.

4. Rebuild the environment, pinned

The most common cause of "the repro doesn't work" is an undocumented environment difference. Pin the artifact by hash not tag, pin the runtime (language, libc, OS), pin the config including which non-default setting the bug needed, and disable the noise (ASLR, JIT, auto-update, telemetry).

Cut the network. network_mode: none whenever real code execution is involved; an internal-only bridge with a loopback sink when the mechanism genuinely needs a hop. Never host networking, never egress. The lab should be disposable enough that total compromise of it costs you a docker compose down.

references/harness-pattern.md has the container hardening block, the file layout, and the safety checklist.

5. Design the oracle before building the exploit

The oracle decides, mechanically, whether the bug fired. Replace every dangerous verb with an inert marker; this costs nothing evidentially and is the core safety technique.

| Real capability | Reproduce it as | |---|---| | Shell / exec / RCE | write MARKER.txt with a fixed UUID, then exit | | Credential theft | read a decoy DECOY_SECRET.txt = not-a-real-secret-1f4c9a | | Exfiltration | POST to a 127.0.0.1 sink that only logs the body | | Email to a person | recipient@example.invalid (RFC 6761, cannot resolve) | | Sandbox escape | compute the escaped path and assert it; never write | | Destruction / encryption | assert the target set was selected; never touch it | | Privilege escalation | assert the privileged state is reachable; do not use it | | Persistence | assert the write location is reachable; do not persist |

The marker must be greppable and impossible to produce by accident. A random UUID baked into the harness is right; pwned is not.

6. Build the four-cell contrast

A single positive result proves almost nothing. Run all four cells and report all four:

| Cell | Input | Version | Expected | |---|---|---|---| | Positive | malicious | vulnerable | marker fires | | Negative control | benign | vulnerable | no marker | | Patch control | malicious | patched | no marker, explicit refusal | | Patch functional | benign | patched | works normally, no regression |

The negative control is what distinguishes "the bug fired" from "my harness always writes the marker", and skipping it is the most common silent error in published repros. The patch functional cell is what decides whether a fix survives production, and almost nobody runs it.

Copy the harness skeleton and layout from references/harness-pattern.md. The harness is a test: it exits non-zero when the story it tells is not true.

7. Minimize

A published PoC is usually 200 lines of scaffolding around the 6 bytes that matter. Finding those bytes is the intellectual core and the part readers value.

• Delta-debug the input: halve, re-run, keep the half that still fires, repeat. scripts/minimize.py implements this against any command that exits 0 when the bug fires, so you rarely need to write it again.
• Bisect the version: git bisect run ./harness.sh. This finds the introducing commit, not just the fixing one, which tells you how long the bug was live and what change caused it.
• Bisect the environment when it fires on the host but not in the container: add config back one item at a time. The item that restores the bug is a precondition you did not know about, and it belongs in the write-up.

Target end state: one paragraph of prose, one code block under twenty lines, one command.

8. Do the patch analysis

This half is not optional, and for most readers it is the more valuable half. Read references/patching.md in full before writing this section. It covers:

• the bug-class-to-correct-fix table (injection, traversal, deserialization, memory safety, authz, SSRF, TOCTOU, SSTI, supply chain, agent tool abuse), and which plausible-looking fixes silently fail for each;
• the four layers of a fix (virtual patch, mitigation, real fix, class elimination) and which clock each runs on;
• how to write a fix that holds: patch at the trust boundary, fail closed, separate rather than escape, never denylist, ship the regression test in the same commit, grep for siblings;
• how to prove a patch holds, which is more than re-running the original payload;
• backporting, rollout sequencing, and removing the temporary control;
• how to audit someone else's patch, which is what a repro blog usually needs.

The governing principle: prefer a fix that makes the bad state unrepresentable over one that detects and rejects it. Parameterized queries beat sanitizing because there is no string to get wrong. Every check you add is a check someone can later reach around.

9. Write the defensive assertion

What control would have caught this, at what layer, and what would it cost? Walk input validation, architecture, detection (write t