Home / Knowledge hub / Virtual patching
Knowledge hub
Virtual patching
Blocking an exploit with a filter while the real fix is still being built.
What it means
Virtual patching means placing a rule in front of a vulnerable application so that attempts to exploit a known flaw are blocked, without changing the application's code. The rule usually sits in a web application firewall, a reverse proxy or an intrusion prevention system.
OWASP describes it as a policy enforcement layer in front of the app. In practice it is used as a stopgap that buys time. The flaw is still in the software. The rule just stops the known malicious requests from reaching it, until the code or the vendor's patch can be changed and deployed.
Why it matters
Real fixes take time. A vendor may not have shipped a patch yet. A rollout may need testing, a maintenance window or a release that is two weeks away. A virtual patch can be live in hours, which shrinks the period in which a public exploit would work.
It also has a danger: it can feel like a fix. Teams add the rule, close the ticket and forget the flaw. Months later the rule is removed in a tidy-up, or an attacker finds a variation the rule does not match, and the original hole is still there.
How it shows up
A good rule describes the weakness and not one exploit string. For a flaw in one parameter, it validates that parameter's shape and rejects the rest. Rules based on a single payload are easy to bypass by changing encoding or case. Always test the rule by trying the exploit and some variations, ideally the same proof used to find the flaw.
Treat it as a compensating control with an end date. Record the rule, the flaw it covers, the owner and the date by which the real fix will replace it. Once the code is fixed, rerun the exploit against the new code, then remove the rule. See WAF for what these filters can and cannot do.
Questions people ask
Virtual patching, answered
Is virtual patching a real fix?
No. It reduces exposure to known attempts while the flaw remains in the code. Only changing the code or installing the vendor patch removes it.
Use it as a short-term bridge.
Can a WAF stop all exploits of a flaw?
Not reliably. Attackers change encoding, split payloads or reach the flaw by another route. A rule written around the weakness does better than one matching a single payload.
Test rules with variations.
When is it a good idea?
When a serious flaw is known or exploited, a fix is not yet possible, and the app sits behind a filter you control.
It also helps for legacy systems that cannot be changed.
How long can a virtual patch stay in place?
As short a time as possible, and with an end date. Rules decay as the app and the filter change.
A rule with no owner is a risk of its own.
How do we check it works?
Run the original exploit and its variants against the protected app and confirm they are blocked, then confirm normal use still works.
Check again after any change to the filter.
Sources
Where this comes from
Related
Terms that sit next to this one
WAF
A filter in front of your application that blocks known bad requests.
Compensating control
A different safeguard used to cover a gap you cannot close directly.
Mitigation
Reducing what a vulnerability can do without actually fixing it.
Patch management
The routine of tracking, testing and rolling out updates across your systems.
Remediation
The actual work of fixing a finding: the change, the review, the release.
Is the hole really covered?
A new rule or a new release is only a claim until it is tested. We re-run the exact exploit against the protected app and the new code to prove it is closed. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.