Key Takeaways

  • Data from VulnCheck's ThreatCon analysis shows that in 2026, the volume of broken or illegitimate public proof-of-concept (PoC) exploits crossed 50% for the first time.
  • Generative AI tools flood open-source repositories with hallucinated, incomplete scripts that mimic security exploits without delivering attacker utility.
  • Most defensive security teams misallocate engineering hours because they treat basic crash scripts the same as weaponized remote access exploits.
  • Spencer McIntyre tracks exploits across two internal filters: whether the script was generated by an AI model and whether the code actually runs.

The Internet Reached a Tipping Point in Broken Exploit Code

For two decades, a published proof-of-concept meant trouble. If an engineer posted a working PoC script to GitHub, security teams scrambled. A live exploit meant an attacker had working code that proved a security flaw was dangerous. You pulled engineers off product features to patch the leak immediately.

That default response no longer works. McIntyre, Director of Exploit Development at VulnCheck, analyzed thousands of public repositories for their ThreatCon review. What they uncovered should change how every tech team triages security alerts.

“Removing the dimension of data about whether or not it was AI-generated, what he pointed out was that with the increase in POCs that we're actually seeing, we saw a tipping point in 2026 where the average number of POCs that looked illegitimate for one reason or another, most often they're they're broken, they don't quite work or like meet our standards for, you know, like doing something worthwhile, tipped to over 50%.”

More than half of the exploit code your team flags on security scanners is broken junk. People generate code with commercial models, slap a CVE label on the repository, and publish it for vanity, security bounties, or search traffic. Defensive pipelines ingest these feeds and sound alarms for security problems that do not actually exist in the wild.

A Crash Script Does Not Prove an Attack Works

Security teams burn their best talent because they confuse a theoretical software defect with real weaponization. McIntyre points out that the industry treats proof-of-concept scripts as a single category, when in practice they fall on a wide spectrum.

“So when we were talking about like vulnerabilities kind of, you know, being like the theoretical flaw, and and the exploit being the real concrete implementation of it, a PoC is kind of like somewhere in between.”

At the low end of that spectrum sits the crash script. A developer feeds bad input into an endpoint, causes an application to throw a segmentation fault, and calls it an exploit.

“Sometimes a PoC is just going to cause a crash, and that would validate the vulnerability, and like I said, a lot of people will take that seriously and they'll apply patches and fix it as as they should.”

A crash confirms that bad input disrupts normal execution. But it does not give an outside attacker arbitrary control over your cluster, database, or identity provider. McIntyre warns that teams treat every single crash PoC as an active breach vector:

“So what we're seeing is that today, your average POC that you find, it's probably not what you're hoping it would be, where it's actually going to truly leverage the vulnerability it says it does and prove some kind of attacker utility.”

When you scramble product engineers to patch a vulnerability that only causes an internal service restart, you stop shipping features for phantom threats.

What to Do With This

Update your vulnerability response runbook tomorrow morning. Pull the last five critical CVE tickets your team triaged based on public exploit chatter, and trace whether the PoC demonstrated actual attacker utility or just caused an unhandled exception. If your triage rule triggers code freezes on unverified public scripts, rewrite it to require proof of functional execution before pulling product engineers away from their roadmap.