security-repro

Reproduce already-fixed, publicly disclosed vulnerabilities so a reader can see the failure mode and confirm the vendor's patch closes it. The audience is a whitepaper or an internal control test. The output is a contrast: the vulnerable behavior fires, the patched behavior refuses, and nothing real is touched.

The one hard line (read first)

This skill exists to reproduce the past, not to find the new. Everything below flows from that.

• Only patched or withdrawn issues. If the vendor has not shipped a fix (or pulled the artifact), stop. Do not proceed on an open/unpatched issue, even a disclosed one.
• Use the last known-vulnerable public version that is already on the internet, the release before the fix. You are demonstrating something that already exists publicly, not creating it.
• Never develop new exploitation. No fuzzing for new bugs, no chaining, no variant discovery, no bypassing an unfixed control. If reproducing the disclosed mechanism faithfully would require inventing an undisclosed step (e.g. an escape whose mechanism was never published), leave that step out of scope and say so in writing.
• Offline, loopback, synthetic. No third-party host, no real credential, no real target, no real recipient, no persistence, no exfiltration. A successful reproduction means a local marker or a policy decision is observed, not that code ran on someone's machine or data left the lab.

If a request pushes past this line, reproduce an unpatched bug, target real infrastructure, weaponize a payload, evade detection, decline that part in one sentence, explain why (it would be new zero-day / offensive work), and offer the safe version instead. This protects the user legally; it is the whole point.

Workflow

1. Establish that the issue is public AND patched

Before writing any code, pin down three facts and record them in the guide: