What is a zero-day?

The term marks a period rather than a technique.

There is a moment when a weakness becomes usable by somebody, and a later moment when a correction exists and can be applied. Between those two, any use of it is a zero-day, whether the method is ingenious or completely routine. After the second moment, the same attack against an unpatched system is no longer called that, though it works as well.

That is the whole of the definition, and the interesting consequences follow from how narrow it is.

Three consequences, and the third is the one to act on.

The label says nothing about difficulty. An unremarkable technique against a weakness nobody has fixed qualifies just as much as an elaborate one. Treating the word as a measure of sophistication leads to overestimating the attacker and underestimating how ordinary the exposure usually is.

Most damage happens after the fix exists. The window in which nothing can be done is by definition short; the window in which something could be done and was not is as long as anybody allows it to be. Attacks against known weaknesses on unpatched systems outnumber genuine zero-days by a wide margin, which is why patching discipline matters more than any defence aimed at the unknown.

Filtering can only buy time here, and only sometimes. Where the HTTP traffic exploiting a weakness has a recognisable shape, a rule can refuse it before it reaches the application, which is virtual patching. That protects against the versions somebody anticipated and not against the ones they did not, and it is a delay rather than a repair.

The honest summary is that no product prevents the category. What preparation does is shorten the period between a fix existing and your systems having it, and make the traffic reaching your application visible enough that something unusual can be noticed at all, which is what operations is about.

Blocking exploit traffic while a weakness remains is covered under virtual patching, and the rest of the vocabulary in this glossary.