Virtual patching — buying time at the edge when a zero-day drops on a Friday

The gap between disclosure and deploy is where you get hit

A serious vulnerability gets disclosed. Within hours there is a working exploit circulating and mass scanning starts. The official fix might be a vendor patch you cannot apply until it ships, a dependency bump that needs regression testing, or a code change that has to go through your release process. That gap — between the exploit being public and your origin actually being fixed — is measured in days for most teams. It is exactly the window attackers count on.

Virtual patching is how you shrink your exposure in that window to minutes instead of days. Instead of changing the vulnerable code, you block the exploit before it reaches it, at the edge, so the unpatched origin never sees the malicious request.

A rule at the edge, not a change to your app

When a vulnerability’s exploit has a recognizable shape — a specific path, a header, a parameter carrying a known payload — that shape can be turned into a filtering rule and pushed to the edge. From that moment every request matching the exploit is stopped before it reaches your server. Your origin stays vulnerable in the literal sense, but the attack can no longer get to it.

Two things make this practical on Smart WAF:

• The OWASP Core Rule Set already covers the exploit classes. Most fresh CVEs are new instances of old families — an injection, a traversal, a deserialization flaw. The maintained ruleset our dual signature WAF engines run catches a large share of new exploits on day zero without anyone writing a thing, simply because the exploit is a variant of a pattern the ruleset already knows.
• Config propagates in under a second. A targeted rule for a specific new CVE is pushed from the control plane to every edge node and picked up through a config-store watch — sub- second, no redeploy of your application, no maintenance window. When minutes matter, the distribution mechanism matters as much as the rule.

Every such change is written to an immutable audit log, so you have a defensible record of exactly what was blocked, from when, in case you need it for incident review or compliance.

Layers behind the signature

A signature is the front line, not the whole defense. Behind it, exploit attempts that come as a flood are shed by L3/L4 early-drop in the kernel before they cost the WAF anything, and clients probing for the vulnerability get an ML entity score from their scanning behavior — so a slow, careful attacker mapping your surface is caught by pattern even before a specific rule exists.

What we don’t claim

This is the honest part. Virtual patching buys time; it is not a substitute for the real fix. A vulnerability with no recognizable request signature — a pure logic flaw, an authentication-bypass that looks like a normal valid request — cannot be virtually patched, because there is nothing distinctive to match on. We will not tell you the edge makes patching optional; it does not. What it does is collapse your window of exposure while the proper fix goes through your normal process, and it does that inline within our ≤5 ms design budget for legitimate traffic.

The right way to think about it: virtual patching is the airbag, not a reason to stop maintaining the brakes.

When the next one drops

Zero-days do not schedule themselves for business hours. If you want a layer that can block a fresh exploit at the edge while your team works the real fix, tell us your domain or read how it works.