There’s a banner hanging next to our stand at BSides.
It says:
Is that marketing bullshit?
Fair question.
So here’s the deal.
For the next 30 days, ThreatCanary is going to try to find 1,000 previously unknown vulnerabilities.
Not known CVEs.
Not scanner hits.
Not an LLM telling us /admin/debug “may present a significant security risk”.
Actual bugs.
Things that weren’t publicly known when we found them. Things we can reproduce. Things with demonstrable security impact.
And we’re starting here:
0/ 1000
That part matters, because we already have hundreds of previously unknown vulnerability findings across routers, embedded hardware, firmware and software moving through validation and deduplication.
They don’t count.
Otherwise we’d be cheating.
CVE isn’t dead. CVE-dependent security is.
For anyone outside the vulnerability-management weeds, CVE stands for Common Vulnerabilities and Exposures. It is the industry-standard system used to give publicly disclosed security vulnerabilities a consistent identifier.
A CVE tells defenders what the world already knows.
That makes CVEs useful—but inherently retrospective. Security teams cannot rely solely on public identifiers, scanner signatures and vendor patches when attackers are already looking for vulnerabilities that have not been named.
Previously unknown vulnerabilities have real offensive value. They represent knowledge that competitors, vendors and potential adversaries may not possess.
That knowledge also has defensive value for ThreatCanary customers. Used within authorised environments, it enables more realistic testing, exposes weaknesses before they become public knowledge and helps organisations prepare for attack paths that conventional vulnerability management cannot yet see.
The security industry has built an enormous machine around roughly this process:
Someone finds bug → vendor gets bug → CVE gets assigned → patch gets released → scanner learns CVE → enterprise discovers it owns thousands of vulnerable things → everyone has meetings → eventually something gets patched.
The attacker doesn’t have to participate in any of that.
A vulnerability doesn’t suddenly come into existence when somebody gives it a number. It was already there. You just didn’t know about it.
The interesting problem is everything it doesn’t.
The clock is disappearing
If you haven’t seen Zero Day Clock, go look at it.
It attempts to measure the gap between vulnerability disclosure and confirmed exploitation using public datasets including NVD, CISA KEV and VulnCheck.
The trend is fairly unpleasant.
Its current reproducibility dataset puts median time-to-exploitation at:
- 2018: 771 days
- 2021: 68 days
- 2023: 5.3 days
- 2024: 0.5 days
- 2025: 0 days
- 2026: 0 days
For the current 2026 cohort, 68% of confirmed-exploitation cases have an exploitation date on or before public disclosure under Zero Day Clock’s methodology.
There are caveats to those numbers. Zero Day Clock documents them, which is why we like the project.
But unless the caveats have somehow invented a time machine, the direction of travel is pretty obvious.
For some vulnerabilities there isn’t much of a patch window anymore.
There is:
before exploitation
and
after exploitation.
Sometimes they happen on the same day.
Patch Tuesday is adorable
On August 11, Microsoft shipped fixes for 400 vulnerabilities. Forty-two were rated Critical. Thirty-seven of those were remote-code-execution vulnerabilities. Three were zero-days, including one already being exploited.
BleepingComputer / 11 August 2026Microsoft August 2026 Patch Tuesday fixes 400 flaws, 3 zero-days400 flaws · 42 Critical · 37 Critical RCE · 3 zero-days Read source ↗And inside enterprises everywhere, an ancient ritual began.
Scanners scanned.
Spreadsheets appeared.
ServiceNow suffered.
Risk scores were argued about.
Change windows were negotiated.
Someone asked whether the production server really needed rebooting.
Everyone started racing the clock.
Then something else happened.
A month earlier, Microsoft had patched CVE-2026-50656, better known as RoguePlanet, a Defender vulnerability capable of giving an attacker SYSTEM privileges.
Then, right around August Patch Tuesday, ShieldBreak appeared publicly.
The researcher described it as a full bypass of Microsoft’s RoguePlanet fix. BleepingComputer reported that independent researchers reproduced the technique. Later analysis also showed that ShieldBreak and RoguePlanet reached the same practical outcome through materially different mechanisms.
It’s worth being precise, too. ShieldBreak isn’t a bypass for one of August’s 400 newly patched vulnerabilities.
RoguePlanet had been patched the month before. And that makes the point better.
While defenders were being handed another 400 vulnerabilities to process, researchers were simultaneously challenging something organisations could reasonably have considered:
done.
Patched.
Then:
not patched enough.
None of this is new, though.
People have been breaking patches forever.
Get the old binary.
Get the new binary.
Diff them.
See what changed.
Ask why.
Start digging.
Bang your head against the computer for a few hours. Yell at the router firmware or Burp Suite.
The interesting part is what is happening right now: when machines get good at digging.
The factory, not the scanner
Most vulnerability tooling starts with something somebody already knows.
Here’s a CVE.
Here’s a signature.
Here’s a vulnerable version.
Go find it.
That’s useful.
But it’s a lookup problem.
We’re interested in a discovery problem.
Give the system a router.
Give it firmware.
Give it an application.
Give it an API.
Don’t tell it where the vulnerability is.
Don’t give it an exploit.
Ask:
How can this thing be made to behave in a way its developer didn’t intend?
Internally, we started calling the system:
The Weapons Factory
Probably not the name our lawyers would have chosen.
The research loop is fairly simple:
- Observe.
- Enumerate.
- Form a hypothesis.
- Test it.
- Fail.
- Pivot.
- Find something weird.
- Reproduce it.
- Prove impact.
Repeat.
A lot.
And there’s one rule we care about enormously:
The LLM doesn’t get to decide it found a vulnerability.
The target decides.
The evidence decides.
The reproduction decides.
An LLM confidently announcing that something looks exploitable isn’t vulnerability research.
It’s autocomplete with self-esteem.
The map feeds the machine
This is also why ThreatCanary’s EASM, API Security and autonomous offensive-security capabilities aren’t three unrelated products sitting next to each other on a website.
The attack surface is the map the research engine reasons over.
Assets.
APIs.
Cloud services.
Exposed interfaces.
Trust relationships.
The weird seams where two systems were connected six years ago and nobody quite remembers why.
That context tells the system where it should look next.
Every new piece of attack-surface intelligence generates more context for the research engine.
Every validated attack path adds something back to the map.
The loops feed each other.
An AI reasoning about vulnerabilities in the abstract is guessing.
An AI with tools, context, evidence and a real target can actually hunt.
Models are commodities. Methodology isn’t.
We don’t have exclusive access to some magical LLM.
Neither does anybody else.
Pretty much every security vendor can access the same class of frontier models.
And this is where a lot of the current AI security conversation gets confused.
Access to a model isn’t a moat.
Tokens aren’t a methodology.
Microsoft has demonstrated this point pretty clearly with MDASH, its own autonomous vulnerability-discovery system.
MDASH coordinates more than 100 specialised agents across different models, with separate stages for discovery, validation, deduplication and proof. Microsoft says the system helped its researchers find 16 vulnerabilities across Windows networking and authentication components, including four Critical RCEs.
Microsoft put it rather well:
“The model is one input. The system is the product.”
Exactly.
The differentiation is everything around the model.
The techniques.
The tools.
The orchestration.
The context.
The ability to recover from failure.
The ability to know what to try next.
And, critically, the ability to prove that what you found is actually real.
Proof before opinion
Every offensive-security vendor says they find things other vendors miss.
Cool.
So let’s stop arguing about it.
Put a number on the clock.
The security industry has spent decades testing security tools against vulnerabilities we already know exist.
Let’s test them against the ones we don’t.
Which brings us to the second part of this experiment.
An open challenge
This isn’t just a ThreatCanary challenge anymore.
It’s a race.
Any vendor.
Any research team.
Any autonomous system.
If you think you can keep pace, join us.
Use whatever models you want.
Use whatever tools you want.
Pick your own targets.
Start at zero.
Thirty days.
Publish your methodology.
Publish what you counted.
Publish what you rejected.
Publish the result.
Same basic rules:
- No known CVEs.
- No scanner findings dressed up as research.
- No duplicates.
- No speculative “AI thinks this might be vulnerable” findings.
- Previously unknown.
- Reproducible.
- Demonstrable security impact.
Show your work.
Because everyone has access to models.
Not everyone has the techniques and methodology required to turn them into a functioning vulnerability-research system.
We think ours works.
We already have hundreds of reasons to think that.
Now we’re putting it on the clock.
And if somebody beats us?
Even better.
That makes the experiment considerably more interesting.
What counts?
We’re defining this upfront because otherwise 1,000 is an extremely easy number to manufacture.
For this challenge, a vulnerability needs to have been previously unknown publicly when we discovered it, be reproducible, and have demonstrable security impact.
We’re not counting:
- Known CVEs.
- Scanner results.
- Duplicates.
- Generic misconfigurations.
- Speculation.
- Unreproducible crashes.
- Six different endpoints that eventually turn out to be the same underlying bug.
If two findings collapse into one root cause, the number goes down.
If a vendor shows us we’re wrong, we correct it.
If we’re not confident, it doesn’t go on the scoreboard.
And at the end we’ll publish the funnel.
Not just the nice number.
How many hypotheses.
How many candidates.
How many known vulnerabilities.
How many duplicates.
How many failed reproduction attempts.
How many actually survived validation.
Because otherwise:
“Our AI found 1,000 zero-days.”
is just vendor bullshit with a large number attached.
No, we aren’t dumping 1,000 exploits
Finding vulnerabilities faster creates another problem.
Someone still has to fix them.
This challenge is about demonstrating discovery capability—not committing to publish the entire vulnerability set.
We can publish the methodology, validation criteria, aggregate results and what the experiment teaches us without releasing the full corpus or exploit material.
Once the challenge is complete, we’ll release a small handful of the zero-days publicly.
Partly as proof. Partly for fun.
The rest remains part of ThreatCanary’s proprietary research.
The objective here is to understand whether vulnerability discovery can be industrialised.
Not to hand the internet a thousand unpatched exploits because it makes for a funny tweet.
And there’s another question hidden inside the experiment.
If autonomous systems can actually discover vulnerabilities at this sort of rate:
can the rest of the industry process what comes out the other end?
Discovery might not be the bottleneck.
Validation might.
Disclosure might.
Vendor remediation might.
Enterprise patching definitely might.
Microsoft says vulnerability-reporting volume is rising as automation matures and researchers increasingly use AI to examine software more often and more deeply than was practical only a few years ago.
The bottleneck is moving.
Test the system, not the promise
If you’re at BSides, come to our stand.
We’re obviously not putting undisclosed zero-days on a conference projector.
What we will show you is the machinery.
We’ll point ThreatCanary at controlled targets containing known vulnerabilities and let you watch the research loop operate.
Discovery.
Reasoning.
Tool execution.
Failure.
Pivoting.
Validation.
Evidence.
What you’re watching in the demo is a known vulnerability.
The system finding it is the same system behind this experiment.
Come and challenge it.
Ask how we validate.
Ask what counts.
Ask what doesn’t.
Try to work out whether we’ve actually built autonomous vulnerability research or just Nuclei with an expensive autocomplete attached.
That’s the point.
Day 1
Maybe we find 1,000.
Maybe we find 300.
Maybe the infrastructure catches fire on day four.
Maybe discovery works beautifully and validation becomes the real bottleneck.
Maybe disclosure does.
That’s why we’re doing it publicly.
The interesting thing isn’t whether ThreatCanary gets a nice round number for a banner.
The interesting question is:
Is vulnerability discovery becoming industrialised?
For decades, vulnerability research has been constrained by a scarce resource:
people who know how to do it.
There are only so many researchers.
Only so many hours.
Only so many competent weirdos willing to spend three days arguing with a router.
What happens when that bottleneck starts moving?
The security industry has spent decades getting very good at managing vulnerabilities we already know exist.
The next problem is different.
What is vulnerable right now that nobody has named yet?
The CVE tells you what the world already knows.
For the next 30 days, we’re going looking for everything it doesn’t.
0/ 1000
Day 1 starts now.