Vuln Repro
End-to-end methodology for reproducing AND patching publicly disclosed, already-fixed...
Install
npx skills add Leanmcp/gateway-skills --skill vuln-repro -g -a claude-code -y- Repository
- Leanmcp/gateway-skills2.1k
- Category
- Design
- Updated
- 28d ago
- License
- MIT
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- Yes, review before use
What it does
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.
