Turn a known/1-day vulnerability or a raw bug into a working, reliable PoC for an authorized target. Load when a CVE/advisory needs weaponizing, a public PoC needs adapting, or "write an exploit/PoC". Signals: a versioned service with a known CVE, a crash/primitive to develop, searchsploit hits.
Installs into .claude/skills of the current project.
Are you the author of Exploit Poc Development?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/noorqureshi-exploit-poc-development)
---
name: exploit-poc-development
description: >
Turn a known/1-day vulnerability or a raw bug into a working, reliable PoC for an authorized
target. Load when a CVE/advisory needs weaponizing, a public PoC needs adapting, or "write an
exploit/PoC". Signals: a versioned service with a known CVE, a crash/primitive to develop,
searchsploit hits.
domain: exploit-dev
type: methodology
stability: learning
modes: [pentest, bugbounty]
severity: high
mitre: [T1203, T1588.005]
tools: [searchsploit, python, pwntools]
schema_version: 1
---
# PoC / exploit development (authorized targets)
## When it applies
You've identified a vulnerability (a versioned CVE, or your own discovered bug) and need a
reliable proof-of-concept to demonstrate impact on an authorized target.
## Why it works
A version+advisory tells you the root cause and the primitive; a methodical build turns that
into repeatable code. For 1-days, most of the work is *understanding and adapting*, not inventing.
## Method
1. **Identify precisely**: exact product+version → advisory/CVE → root cause and affected code
path. `searchsploit <product version>`; read the advisory and any public PoC.
2. **Understand before running**: never fire an unread exploit at a target — read the code, know
what it does (esp. anything destructive), and check it matches your exact version.
3. **Set up a local mirror** when possible (same version in a VM/container) to develop safely.
4. **Build incrementally**: reach the vulnerable code → trigger the primitive (leak/overwrite/
inject) → stabilize → deliver payload. For web, a clean scripted request chain; for binaries,
pwntools with the leak→control→shell steps.
5. **Make it reliable & minimal**: parameterize target/port, add checks, remove noise; it must
reproduce for a report/triager.
## Gotchas
- Public PoCs are often broken, version-specific, or backdoored — read every line before running.
- Match the exact version/build; an off-by-one minor version silently fails or crashes the service.
- On live bug-bounty targets, prove the primitive without destructive payloads (no DoS/data loss).
## Verify success
The PoC reproducibly demonstrates the vulnerability's impact (shell, read, auth bypass) against
the authorized target/version, with clear steps.
## References
Exploit-DB/searchsploit; pwntools docs; the vendor advisory/CVE for the specific bug.