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.
Scanned 9/22/2026
npx -y skills add NoorQureshi/SploitAgent --skill exploit-poc-development --agent claude-codeInstalls 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 automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/noorqureshi-exploit-poc-development)More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.
---
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.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!