A Proof of Concept Is Not an Exploitable Risk

“There is a PoC online, so we have a full compromise on our hands.”

No. Say the rest of it, because you are one sentence from a priority-one incident and a slide with a red skull on it.

A proof of concept is not an exploitable risk assessment.

A PoC can establish something important.

Under stated conditions, a flaw exists and a trigger reaches it.

That is evidence.

It may be excellent evidence.

It is not evidence that your system is reachable.

That the trigger produces usable control.

That mitigations do not matter.

That the result is reliable.

That the result reaches a meaningful privilege or data boundary.

Separate claims.

Treat them as one and a useful technical signal becomes a binary label in a frightening font.

The distinction isn’t academic.

In 2026, Anthropic measured n-day work against 18 source-available Firefox vulnerabilities. A leading model reproduced a PoC crash for 14, and reached a full working code-execution exploit for 8.

Against 21 closed-source Windows kernel vulnerabilities, it triggered 18 crashes and reached a complete privilege-escalation chain for 8.

A crash is a stage.

A consequence is another stage.

Those are dated numbers from those tested codebases, not a universal exploitability rate.

They are still a rather efficient way to ruin the slogan.

1. “But the PoC Proves the Bug Is Real.”

Yes.

It proves the bug is real under the conditions the PoC demonstrates.

That can be a crash.

An invalid state.

A bad pointer dereference.

An over-read.

A double free.

A fuzzer produces many such crashes.

They can be reproducible, genuine, and useless for exploitation, because the corrupted value is not predictable, the affected memory has no security-relevant role, or the observed result gives nobody a capability they can steer.

For a memory-safety flaw, your triage question isn’t “did it crash?”

It is whether the flaw yields a controllable primitive.

A write primitive means attacker-influenced data reaches a location later trusted as code, a code pointer, or a size.

That is a materially stronger claim than “the test process fell over.”

Calling both outcomes “full compromise” is like calling a smoke alarm and a burnt building the same event because both involve fire.

Useful systems don’t work that way.

Neither should your vulnerability triage.

2. “But Attackers Can Modify Public Code.”

Of course they can.

Public code reduces the work needed to understand a demonstrated trigger, adapt it to a build, or investigate adjacent conditions.

Which is why a public PoC deserves attention.

It doesn’t remove the conditions your target imposes.

ASLR changes code, heap and stack locations on each run. A write primitive alone does not establish a usable target address.

On an ASLR-hardened target, an information leak or read primitive is commonly needed before a control-related value can be directed meaningfully.

DEP, also called NX, creates a different constraint: stack and heap memory are not executable.

Control-flow integrity, pointer authentication and sandboxing add more conditions.

Those are layers operating at the memory, control-flow and process-isolation layers.

A public trigger doesn’t dissolve them by being on GitHub.

That would be a remarkable software feature, and one the rest of the industry has somehow failed to advertise.

Your question is specific.

Which primitive does the demonstration establish?

Which mitigation is enabled in this deployment?

What additional condition would be necessary for the claimed consequence?

That question changes a response.

“Someone can modify code” doesn’t.

3. “But the Affected Version Is Deployed.”

Good.

You have established applicability.

You have not established consequence.

An affected version can sit behind an unavailable feature.

A disabled parser.

An authentication boundary.

A private management path.

A compensating control.

A mitigation that changes the result.

Your assessment needs the version and configuration, the exposed interface, required access, trigger preconditions, applicable mitigations, and the privilege or data boundary after the trigger.

The Stagefright timeline shows why even the word “patched” needs handling with care.

Joshua Drake reported the Android media-library flaws to Google in April 2015. Google incorporated fixes into internal source repositories within two days, and core patches were public by early May.

Yet Zimperium assembled a Handset Alliance of more than 25 manufacturers and carriers on 1 August, because a source-tree fix still had to become vendor firmware, and then reach actual devices.

The flaws were publicly disclosed at Black Hat USA on 5 August 2015, with a second presentation at DEF CON 23 on 7 August.

The durable point isn’t a museum label about Android.

It is that “your vendor has a patch,” “the version is affected,” and “this deployed fleet is remediated” are three different operational facts.

4. “But We Cannot Know Exploitability Exactly.”

Correct.

Security work continues despite the absence of omniscience.

Exploitability is conditional.

Bug class.

Target build.

Configuration.

Access.

Mitigations.

Environmental variation.

Intended consequence.

The response is not to pretend the condition set doesn’t exist.

It is to record it, validate the conditions you can validate, and state the remaining uncertainty.

Memory corruption and logic flaws show why this matters.

A memory-corruption path can depend on a controllable write, an information leak, and a viable route through ASLR and DEP.

An Insecure Direct Object Reference is an authorization failure.

Your application authenticates a user and fails to verify ownership of the particular order, document or user record requested.

No crash.

No memory corrupted.

That logic flaw can work identically on every unpatched instance, because the problem is your application’s authorization decision.

Treating every PoC as a memory-corruption reliability problem is as inaccurate as treating every incident as a password reset.

Different failure classes require different evidence.

5. “But Waiting for Exploit Intelligence Is Dangerous.”

Yes.

Waiting for a named weaponized exploit before acting is a poor policy.

Project Zero’s published standard policy gives a vendor 90 days after notification to make a patch available, then 30 days before full technical disclosure.

With an approved grace period that becomes 104 days to patch and 120 days from report to full detail.

For vulnerabilities already exploited in the wild, your policy uses 7 days, a 3-day grace period, and the same 30-day post-patch window.

Full detail can arrive as early as day 37.

CERT/CC uses a separate 45-day guideline, and can adjust for circumstances such as active exploitation or a standards-level fix.

Those clocks govern publication.

They do not certify that an exploit is reliable.

Nor do they grant your deployment immunity while the calendar is still polite.

Defenders don’t wait.

They validate whether the exposed path exists, patch when the risk warrants it, and apply compensating controls where patching cannot happen immediately.

Exploit intelligence changes prioritization.

It is not the only condition under which a vulnerable internet-facing service becomes worth fixing.

6. “But a Successful Demonstration Is Reliable Enough.”

No.

Repeating a trigger in a prepared environment is not the same claim as producing a usable outcome consistently across the environments that matter.

Reliability is operational.

It includes whether a result survives target variation.

Whether failures interrupt the intended consequence.

Whether failures create defensive signals.

The plain example: an exploit succeeding 10% of the time, against a target that logs and alerts on crashes, produces nine failed attempts in ten.

Not merely inconvenient.

Potentially self-defeating.

Which is why “it works once” is not a risk rating.

It is an observation.

A demonstration, a reliable exploit, and a system-specific consequence are different claims, and each needs its own evidence.

There is no mystical conversion at the second successful run.

A flaky demonstration does not graduate into dependable operational impact because somebody added a check mark to a ticket.

7. “But Mitigations Only Make It Harder.”

Sometimes they make it harder.

Sometimes they interrupt the relevant primitive early enough that a chain no longer works in the tested conditions.

Different outcomes.

Your mitigation stack can include ASLR, DEP, control-flow integrity, pointer authentication and sandboxing.

Each operates at a different point.

Address knowledge.

Executable-memory policy.

Permitted control-flow transitions.

Pointer integrity.

Process containment.

Name the layer, and establish whether it is present in the actual build.

Do not wave vaguely at the word “hardened.”

Apple’s Memory Integrity Enforcement is a dated example worth handling precisely.

It shipped on iPhone 17 and iPhone Air A19 and A19 Pro chips after a five-year development effort, uses hardware memory tagging across the kernel and more than 70 userland processes, and Apple’s own offensive-research team reported it could not rebuild six tested real-world exploit chains around it.

That is Apple’s result.

Not an independently replicated universal conclusion.

But it illustrates your assessment question.

Does the mitigation add work later in a chain?

Or does it stop the demonstrated corruption primitive before later stages begin?

The answer materially changes your risk decision.

8. “But There Is a Market for Full-Chain Exploits.”

There is.

That fact supports precision, not panic.

Zerodium’s last public price list reached $2.5 million for a full-chain zero-click Android exploit and $2 million for iOS. RAND’s 2002-2016 zero-day study described full-chain iPhone compromises at roughly $1 million.

Dated market observations.

Not a price catalogue for your next incident.

They reflect a technical distinction.

A reliable full chain against a hardened current target can require several independently discovered and independently weaponized flaws.

A different proposition from a public PoC for one disclosed bug.

Only 1.1% of the addressable disclosed-vulnerability population was confirmed exploited in the wild.

An affected component is not automatically a rational attacker investment.

This does not mean a lower-cost or already-disclosed n-day cannot be useful to an attacker.

It means you should assess the particular path, exposure and consequence, rather than importing the maximum imaginable capability into every ticket.

Threat modelling is not the art of assuming every stranger owns a Formula One team.

9. No, This Does Not Mean Public PoCs Are Harmless.

They aren’t.

Public PoCs change the situation.

They demonstrate a trigger, make research easier, reduce uncertainty for defenders, and reduce some of the effort needed to investigate the flaw.

Coordinated disclosure exists partly because publication alters the balance between remediation and misuse.

It also does not mean your team should wait for weaponization.

Project Zero’s deadlines, CERT/CC’s 45-day guideline and the Stagefright disclosure process all make the same broader point. Patch availability, public detail and fleet remediation move on separate clocks.

Stagefright’s post-disclosure record included CVE-2015-3864 on 13 August 2015 and a related “Stagefright 2.0” round on 1 October.

Disclosure did not make the underlying remediation problem disappear.

The correction is narrower and more useful.

Do not call every public demonstration a full compromise.

State the demonstrated trigger, the actual preconditions, the mitigations, the observed consequence, and what your deployment evidence says.

That is not minimizing the risk.

It is describing it.

10. “But This Sounds Like an Excuse Not to Patch.”

Then you have confused triage with delay.

Patching is a control.

It removes or changes the vulnerable condition.

An exploitability assessment determines urgency, compensating controls, validation scope, monitoring, and whether the residual risk is acceptable during remediation.

Complementary activities.

Where a patch cannot deploy immediately, reduce reachable exposure, constrain the vulnerable path, and monitor for relevant defensive indicators.

Do not reproduce offensive tradecraft in production in the name of “confirming” a public PoC.

A controlled environment exists for a reason.

Production is not a research lab with better uptime.

The legal boundary is equally unromantic.

A bug-bounty policy’s safe harbour is scope-bounded. disclose.io calls a programme Full Safe Harbor only when it specifies in-scope properties, compensation terms, reporting channels and a disclosure policy.

Work outside authorized scope forfeits that contractual protection.

Validation needs authorization as well as technical discipline.

11. What You Should Actually Do

Validate the affected version and configuration in a controlled, authorized environment. Record the component, build, enabled feature, exposed interface, required access, trigger conditions, mitigation state, observed reliability, and post-execution privilege or data boundary.

A finding that cannot name its boundary has not finished its own sentence.

Prioritize internet-facing and high-consequence paths. Apply the vendor patch where available.

Where remediation takes time, apply compensating controls that reduce reachability or constrain the affected feature, then monitor defensive indicators appropriate to the deployed environment.

The action comes from the path to consequence, not from the theatrical quality of the PoC’s README.

Track patch deployment separately from patch publication. For distributed fleets, verify that the updated build actually reaches the systems that matter.

Stagefright is the warning label.

A fast source fix did not manufacture OEM engineering capacity or carrier approval speed.

Retest after remediation. Confirm the affected version or configuration is gone, the compensating control still applies, and the path no longer reaches the recorded boundary.

Keep the validation record.

It is what turns a security decision into something another engineer can review, rather than a folk memory about a scary repository.

12. The Model Is Not Complicated.

A PoC says: under these stated conditions, this trigger demonstrates a flaw.

A reliable exploit says: under these target conditions, a controllable path reaches this intended consequence consistently enough to be operationally usable.

A system-specific risk assessment says: this deployment has these versions, configurations, exposures, mitigations and consequences.

Therefore this is the action to take.

Three different claims. Keep them different.

Public PoCs deserve prompt, disciplined attention.

Patch vulnerable systems.

Contain exposed paths.

Validate in controlled environments.

Monitor what your deployment can actually show.

Retest after remediation.

Just do not tell your review meeting that a demonstration and a full compromise are the same thing.

They are not.