There's this concept we've been thinking about and researching for 3 years, and it's affecting the cybersecurity industry at the moment. And it’s all about speed.
I spent a lot of years on the attacking side of vulnerability disclosure, and the thing that still blows my mind is how differently attackers operate from defenders. You’d think they’d be two sides of the same coin: one wants in, the other wants to keep them out. But they don’t even run on the same clock. Attackers start the moment a patch or other intel lands. Defenders start when a CVE number shows up in their tooling. That gap used to be wide enough to patch in. Today it has collapsed, and there are far more CVEs to get through.
It usually plays out something like this: A vendor pushes a fix to GitHub. Someone diffs the patch and posts about it. Within a few hours there are people working out how to trigger the bug, and within a day or two there's a working exploit, available to both malicious and good-faith researchers.
A public proof of concept turns up, sometimes even before the CVE is assigned or officially published by cve.org. After a CVE gets assigned, eventually CISA adds it to KEV when there’s sufficient evidence of malicious exploitation. In that order. Every defensive tool you own keys off one of those last three events, which means every defensive tool you own may be late every single time, depending on the intel they can collect. Zero Day Clock is one of the first publicly attestable resources that demonstrates this with real numbers. In the first nine months of 2026, 72,812 CVEs were published and 845 were catalogued as exploited in the wild. 137 of the ones in the first half of the year were exploited on or before the day they were disclosed. So for a decent chunk of what actually gets used, the clock has already run out by the time a CVE number is assigned.
That is a growing problem in cybersecurity right now, because the tools that are available to us are typically only alerting us to the existence of bugs after the CVE number exists.
Ethiack has built something that works inside that gap, and we’ve made it public! It’s called Ethiack Zero: the public record of emerging 0-days, validated in hours. This week it did exactly that: when two PHP vulnerabilities (CVE-2026-109618 and CVE-2026-109619) started circulating, Zero started analyzing those entries that came from public signals and validated them, but couldn’t figure out the full exploit yet. Generating code that proves that the vulnerability exists is faster and more important to defenders than a full exploit, so our research team shipped a highly reliable module to production within hours.
Why this gap exists
When a new vulnerability signal shows up, a security team has to know about it, the patch if there is one, and keep tabs on whatever people are saying about it. Is there a public PoC yet? Is the public PoC real, or malware, or something to confuse the defenders? They have to work out what actually changed, whether it's real, and whether it's worth chasing.
That can be at least a day's work for a skilled researcher when it comes to a complex bug. Some are hard and have to be parked until more details surface. Tens of thousands of vulnerabilities get published a year, so only a tiny fraction ever get a confident detection module or a working proof of concept. The rest live in a scanner as a version check and a CVSS score, which ignores security backports and other mitigations.
Most tooling in this space starts at t=0, when the CVE is officially published. Some actors generate proofs of concept without ever validating them, or publish checkers that are so unreliable they give a false sense of security. KEV is useful to prioritize, and KEV is usually the last thing to move, or is based on honeypots that don’t prove necessarily that the exploitation is actually malicious, since there are also good-faith security researchers trying to report those.
What Ethiack Zero actually does
A signal turns up somewhere in the world: a published CVE, an advisory, a patch, a bug that has no number yet. Zero turns that signal into a check Ethiack's engine can run against every customer, and proves the check works before it trusts it.
The pipeline contains five steps:
- A signal arrives from public feeds, advisories, mailing lists, etc.
2. An agent reads the patch and consumes the information and works the real product until it can trigger the bug, coming back later if it needs more detail. This may include reverse engineering as well.
3. It writes a detection module.
4. It runs that module against the vulnerable version and the fixed version and compares the results.
5. If confidence is high it ships on its own, and if not, it waits for a person.
The part that matters most technically is where it starts, because time is key. Zero is watching the places vulnerability information first appears, which is usually a patch, a GitHub advisory or a researcher's post, and it starts from that moment rather than waiting for the official CVE information. Everything on the feed is anchored to cve.org publication because that's when the information becomes broadly known, but the whole point is for Zero's marks to take place before that moment.
As I write this, Ethiack Zero has attempted 2,367 vulnerabilities and validated 1,046 of them (44%). Its median time to validate is about four and a half hours after the CVE is published. For comparison, KEV puts the median time to confirmed exploitation in the wild at two days, and since KEV is a lagging signal, real attackers are often faster than that. And 7% of entries were validated before t=0, which means before the CVE officially existed at all.
Yesterday, in practice
On 21 October, two PHP vulnerabilities started circulating. Early public information was thin and conflicting. Zero picked up the signal, validated the entry as a contextual technique, and the Ethiack research team shipped a detection module the same morning.
To be precise about what this is: a detection, not a working exploit. We’re not claiming to have a public proof of the full attack path after a few hours, and the record doesn’t either. That’s the point of a public timeline: it shows what was known, and when.
Why it's public
The obvious commercial move is to keep something like this behind a login. Ethiack went the other way because the information asymmetry is the problem. Attackers already have these signals and defenders mostly get them late or not at all.
The feed is open and every timestamp is there for anyone to check. If a big vulnerability drops and you want to know whether anyone has actually reproduced it yet, this is meant to be the first place you look. We also try to understand if PoCs are valid or slop as best as we can.
That's the community side of it, and it's the part I care about most. Researchers, bug bounty hunters and blue teams get the same early signal attackers have been working from, plus a straight answer on whether it's real, without needing to be an Ethiack customer. If you work in this industry, it's worth bookmarking.
What it means if you're a customer
There is a commercial side to this too. If you're an Ethiack customer, when Zero validates a signal, that validated module starts running against your attack surface straight away and keeps running. You're not waiting on a scanner signature or a CVE. If you're exposed to something Zero has proven, you hear it from Ethiack, sometimes before there is a CVE.
Go and check it
Zero is live at zero.ethiack.com. Have a look at the feed, start with an entry like the PHP one and compare the dates against cve.org and KEV, then search for a technology you care about. If something looks off, please tell us. We are still improving it but we believe this is a contribution to keeping the Internet safe, sustainable and free.
Crazy times!