Cybersecurity glossary
What is a Proof of Concept (PoC)?
Learn what a security proof of concept (PoC) is, how PoC exploits differ from weaponized malware, when to run or publish them, and how defenders use PoCs safely.
Definition
In cybersecurity, a proof of concept (PoC) is a minimal demonstration—often a script, request sequence, or lab exploit—that shows a vulnerability is real and reachable, without necessarily delivering a full, reliable, or stealthy attack tool.
Why PoCs settle arguments
Severity debates stall when one side says “theoretical” and the other says “critical.” A proof of concept (PoC) collapses that gap: a concrete reproduction that shows the vulnerability can be reached and abused under stated conditions.
Good PoCs are small, reversible, and focused on evidence—not ransomware payloads.
Anatomy of a useful security PoC
State preconditions
Document version, configuration, auth state, and network position required for success.
Minimize the trigger
Use the shortest request, input, or binary stub that demonstrates the flaw.
Show clear evidence
Prove impact with a benign marker: calculated field, DNS callback, or safe file write.
Avoid destructive payloads
Do not delete data, spam customers, or persist malware to “prove” severity.
Package reproduction notes
Include exact steps so defenders can validate fixes without reverse-engineering your demo.
PoC types you will encounter
HTTP / API PoC
Curated requests (curl, Burp) showing injection, authz bypass, or SSRF.
Scripted exploit stub
Python or Go snippets that automate a multi-step trigger reliably in a lab.
Binary / memory PoC
Crash or controlled write demos for memory corruption—often lab-only.
Detection PoC
Safe tests written so blue teams can verify IDS/WAF rules without harm.
Handling PoCs without creating risk
| Situation | Guidance |
|---|---|
| Incoming bug bounty PoC | Run only in isolated staging with reviewed code and scoped credentials |
| Public GitHub exploit drops | Assume scanners will follow; patch exposed assets first, then study offline |
| Vendor disputes severity | Share a minimal PoC under NDA/CVD rather than escalating publicly early |
| Change validation | Re-run the same PoC after the fix; failure of the PoC is your acceptance test |
| Production emergency | Prefer vendor patches and virtual mitigations over live exploit testing |
- Require written authorization before executing any third-party PoC.
- Prefer benign evidence of impact over noisy or destructive payloads.
- Store PoCs in a controlled repo with access logging—not random chat attachments.
- Strip secrets and customer data from PoC artifacts before sharing.
- Treat public PoC release as a patching deadline accelerator.
- Pair each accepted PoC with a detection idea or regression test.
- Never paste untrusted PoC binaries onto jump hosts or production bastions.
- Credit researchers and follow disclosure timelines when publishing your own demos.
The practical takeaway
A PoC proves a vulnerability is real enough to act on. Keep demos minimal, authorized, and safe—then use them to drive remediation and detection, not theater.
If you cannot reproduce a finding with a controlled PoC or clear steps, you do not yet have a shippable security ticket.
Related security terms
Exploitability
PoCs help prove whether a theoretical flaw is practically exploitable.
Responsible Disclosure
Guidelines for sharing vulnerability details and PoCs without reckless harm.
Bug Bounty
Programs where researchers often attach PoCs to validate reports.
Penetration Testing
Engagements that may develop private PoCs to evidence findings.
Exploit Prediction Scoring System (EPSS)
Public PoC availability can correlate with rising exploitation likelihood.
Frequently asked questions
What is a PoC in simple terms?
A PoC is a small demo that proves a security bug works—enough evidence to convince engineers, not necessarily a full attack suite.
Is a PoC the same as an exploit?
A PoC is a type of exploit artifact focused on demonstration. Weaponized exploits add reliability, automation, evasion, and payload delivery.
Why do researchers publish PoCs?
To prove impact, enable defenders to validate patches, and advance science—ideally after coordinated disclosure timelines.
Are public PoCs dangerous?
They can accelerate both patching and attacker scanning. Organizations should assume public PoCs will be weaponized quickly.
Should every bug report include a PoC?
Strong reports usually include reproduction steps. A working PoC reduces debate but must stay within authorized scope and safe payloads.
Can I run random GitHub PoCs against production?
No. Only test systems you own or are authorized to assess, in controlled environments, with reviewed code.
How do blue teams use PoCs?
To confirm exposure, write detections, validate WAF/virtual patches, and verify that remediation actually blocks the path.
References
Explore authoritative guidance and frameworks related to proof of concept (poc).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.