Zero day attacks misuse a flaw that the affected vendor has not yet fixed in public, so usual patch advice arrives only after exposure has begun.
The name points to the timing of the flaw, not to a single technique, and the impact can range from quiet theft to a full outage.
How it works
Defenders feel pressure because signatures and patches keyed to a known flaw do not exist on the first day.
Reducing what an outsider can reach, limiting account power, and watching for strange behavior still cut harm even while the specific flaw is unknown.
When a fix appears, speed matters, but so does checking that the fix is genuine and that it does not break a critical process.
Afterward, teams should ask which control would have limited damage if the flaw had remained secret for longer.
Concrete examples
- A public web service is compromised through a flaw the vendor acknowledges only the next day, after data has already left.
- A mail client flaw lets a crafted message run code before any advisory exists, and the first sign is an odd outbound connection.
- A widely used library flaw forces many products to ship updates in the same week once the vendor publishes a fix.
Protective measures
- Expose only services that customers or operations truly need, so an unknown flaw has a smaller reachable surface.
- Give accounts the least power that still lets people work, which limits damage while a fix is not yet available.
- Subscribe to vendor advisories and rehearse emergency change so a new fix can move without chaos.
- Watch for unusual process behavior and unexpected outbound traffic, because those signs do not require knowing the flaw in advance.
Related articles
The article What is a threat actor? identifies who benefits from striking before a public fix exists.
The article What is an attack vector? helps name the path even when the flaw itself is still new.
The article What is a virus in computing? contrasts host based viruses with other unwanted code, separate from flaw timing.