Virtual patching is useful because it can block known exploit attempts at a layer you control, such as a web application firewall, while the real code fix is built and tested. It buys days or weeks for systems that cannot be patched at once. It is a temporary shield, not a cure.
What is a virtual patch?
OWASP's virtual patching best practices page describes the term as originally coined by intrusion prevention system vendors, and now used mostly for web application firewalls, though it applies to other protocols. The idea is a rule outside the vulnerable application that stops the malicious request before it arrives.
The vulnerability stays in the code. What changes is that the known way to trigger it is intercepted.
When does it make sense?
When a real patch is not available or cannot be applied yet. Examples:
- A vendor has not shipped a fix for a flaw already being exploited.
- The fix needs a risky upgrade that must go through testing and a change window.
- The system is legacy, unsupported or embedded, and cannot be updated at all.
- An application is third-party and you do not control the source.
NIST SP 800-40 Revision 4 on enterprise patch management accepts that patching is not always immediate and recommends a strategy that includes risk-based prioritization and alternative mitigations. Virtual patching is one such mitigation.
What are its limits?
A rule is only as good as its match. If it blocks one exact pattern, an attacker may vary the request to slip past it. Rules written from a vague description of the bug are the weakest. Rules can also block legitimate traffic, so they need testing.
Virtual patching cannot help where the exploit does not travel through the layer you filter: an attack from inside the network, through a different protocol, or via a path your gateway does not see. And it leaves the vulnerable component in place, so a configuration slip that bypasses the firewall exposes the original flaw again.
How do you do it properly?
OWASP's guidance frames virtual patching as a process: prepare before you need it, identify the vulnerability, then analyze, create and implement a rule, and test and recover. The important preparation is having the tool and the authority ready, so a rule can be deployed in hours when an advisory lands.
Start in monitoring mode where possible, to see which requests would be blocked before you enforce. Write rules tied to the vulnerable parameter or route, not just a generic attack string. Record each rule with the vulnerability it covers and a removal date.
A constructed example: an advisory says a login form field on a third-party portal is injectable. The vendor patch is two weeks away. The team deploys a rule that rejects requests where that field contains certain characters, runs it in log-only mode for an hour and sees no legitimate matches, then switches to blocking. They also restrict the portal to the corporate VPN. When the vendor's fix arrives, they apply it in the normal window and delete the rule.
What should you do about the root cause?
The real fix is the real patch. Track every virtual patch as an open vulnerability with an owner, and treat a rule that has been in place for months as a risk, not a resolution. Knowing which findings are actually reachable in your code helps you decide which need a virtual patch at all.
Safeguard's reachability analysis can show whether a vulnerable function is called by your application, and its policies and gates can hold a release until a fix lands. Those help with scoping and follow-through; the filtering rule itself lives in your gateway or firewall.
How to check or apply this
- Confirm you have a filtering layer in front of each exposed application and know who can change its rules.
- When an advisory arrives, check whether you use the affected component and whether it is reachable.
- Write a narrow rule tied to the specific route or parameter, test in log-only mode, then enforce.
- Add network restrictions where they are cheap, such as limiting access to a VPN.
- Record the rule, the advisory, an owner and an expiry date.
- Apply the real patch and remove the rule.
Quick check
Does a virtual patch fix the vulnerability?
No. The flaw remains. The rule blocks a known route to it, so you still need the real patch.
Sources
Last reviewed: 18 October 2026.
