Proof-of-Concept (PoC) Exploit

A proof-of-concept (PoC) exploit is a demonstration — typically working code — that verifies a claimed security vulnerability is technically valid and exploitable. PoCs vary in capability: a minimal PoC may only demonstrate that a crash or unexpected behaviour occurs, while a weaponised PoC delivers a full payload (e.g. remote code execution, credential theft). Security researchers publish PoCs to establish credibility, accelerate vendor responses, and enable defenders to test their own mitigations. PoC publication typically occurs after a patch is released (coordinated) or when a vendor has failed to respond within the disclosure deadline (uncoordinated). A public PoC dramatically reduces the effort required for an attacker to exploit the vulnerability.

The CRA's Article 14 notification requirement is triggered by active exploitation — not by the existence of a PoC. However, a public PoC is a strong indicator that active exploitation is imminent or already underway, for several reasons:

• Automated exploit frameworks (Metasploit, etc.) incorporate public PoCs within days.
• Threat actors scan for unpatched vulnerable systems within hours of PoC publication.
• The gap between PoC publication and first recorded exploitation is measured in days, not weeks.

When a public PoC for your product's vulnerability appears, treat it as a near-certain active exploitation signal: accelerate patch release, notify your CSIRT proactively, and monitor threat intelligence feeds for confirmed exploitation reports.

During a coordinated disclosure, researchers may share PoC code with the manufacturer to facilitate triage and validation. Manufacturers should:

1. Request the PoC — a PoC accelerates internal validation; a vulnerability that cannot be reproduced internally may be disputed or deprioritised incorrectly.
2. Keep it confidential — the PoC should be shared only with the development team on a need-to-know basis; leakage extends the attack window.
3. Negotiate PoC publication timing — most researchers are willing to delay PoC publication until after a patch is released; formalise this in the disclosure agreement.
4. Do not demand PoC suppression indefinitely — requiring a researcher to permanently withhold the PoC is unreasonable; the norm is PoC release concurrent with or shortly after the patch.

If a researcher publishes a PoC before a patch is available, immediately assess whether exploitation is occurring and trigger the Article 14 notification process.

Not all PoCs represent equal risk:

• Crash PoC (DoS) — demonstrates a denial-of-service condition; exploitation causes service disruption but not code execution. Lower severity than RCE PoCs but still urgent for availability-critical systems.
• Authentication bypass PoC — demonstrates that access controls can be circumvented; severity depends on what is accessible post-bypass.
• RCE PoC — demonstrates arbitrary code execution; the highest-severity class; requires immediate patch release regardless of CVSS methodology.
• Weaponised exploit — a PoC that delivers a complete payload against a specific target; effectively an active attack tool. If discovered for your product, assume active exploitation.

The CVSS Temporal Score's 'Exploit Code Maturity' metric formally accounts for this progression (Proof-of-Concept → Functional → High), allowing advisories to reflect changing risk as PoC sophistication evolves.