Virtual patching, also commonly known by the less catchy phrase ‘just in time patching’ is the practice of addressing a vulnerability without changing the code. It does this by blocking the specific attack pattern that can be used to exploit the vulnerability.
Usually, if you’re fixing software, a patch will address the code within it – sort of like stitching up a tear in a jacket sleeve. With virtual patching, you’re basically applying a strong, weather-resistant patch on top of that tear, instead of sewing the tear together.
Why it's suddenly (more) relevant
Both approaches to patching have their uses, but virtual patching is growing increasingly central to modern web security. It’s ideal for avoiding downtime, since the software doesn’t need to be taken out of commission while the code is rewritten, and it’s much faster, too. In an era when attackers can exploit CVEs from the moment they become known, that’s incredibly valuable.
Critical-infrastructure and government systems often can't patch on attacker timescales. They need an option that immediately addresses potential attacks and keeps sensitive information secure.
How it actually works in practice
A virtual patch is a new rule added to the WAF’s (Web Application Firewall’s) existing rule set. A WAF's normal rules are there to protect against the standard threats that all software faces when it’s connected to the worldwide web. Things like SQL injections, bot signatures, and rate limits. When there’s a vulnerability in the code, you need to complement that existing rule set with a virtual patch – basically, to change how traffic is allowed to flow into your application.
It’s a temporary fix that can act as a protective shield while developers work on the code with more time and less pressure on their shoulders.
The catch
There are two ways to create a virtual patch: by following generic rules and blanket defenses in an attempt to secure the vulnerability as fast as possible, or by creating rules that are targeted at the specific exploit path and whatever is exposed on the other end of it.
As you can imagine, which approach you take makes a massive difference to your end result.
Broad and ‘catch all’ rules risk losing customers over WAF false positives. Why? Because they’re so broad and so ‘catch all’ that they end up catching legitimate traffic in the crosshairs, alongside the actual, real attacks looking to exploit the vulnerability you’re trying to patch.
The alternative is targeting rules to the specific, validated exploit path rather than blocking broadly.
