Virtual Patching: Buying Time for Vulnerable Web Apps Without Pretending They Are Fixed

A web application firewall that has spent years in report-only mode is one of the most common things I find in security reviews. It was installed, it logs everything, and on the day it was actually needed, it did nothing.

Here is a typical case. An authenticated scan finds an exploitable SQL injection in an old module of a web portal. The original developer is gone, and fixing and testing the code will take six weeks. What do you do in the meantime? This is where virtual patching earns its place.

What virtual patching means

A virtual patch is a narrow rule in a layer in front of the application, usually a WAF, that blocks malicious requests against one specific vulnerability before they reach the code. The vulnerable code is still there; only the path to it is closed. It buys time. It does not replace the fix.

Timing matters more than it used to. VulnCheck's State of Exploitation 2026 report found that 28.96% of the vulnerabilities first exploited in 2025 were exploited on or before the day their CVE was published. A multi-week development cycle simply does not match that speed.

What a WAF can and cannot cover

• Good fit: SQL and command injection, XSS, path traversal, dangerous file upload on a known path.
• Poor fit: business logic flaws, broken access control and source code disclosure. The attacker's request looks perfectly normal, so a WAF cannot tell it apart.
• Start from evidence: build the rule from a confirmed scanner finding with the exact path and parameter, not from a guess. Several DAST tools can export findings directly as WAF rules.

A practical rollout

1. Inventory every web application and API with two owners: who fixes the code and who runs the WAF.

2. Run authenticated scans; unauthenticated scans miss most of the application.

3. Triage findings into "virtual patch now", "code fix only" and "urgent".

4. Apply each rule only to the affected path, observe it briefly in report mode, then block, and rescan to confirm.

5. Give every virtual patch an owner and an expiration date, keep the development ticket open, and remove the rule after the fixed code passes a rescan.

The same staged approach gets a WAF out of report-only mode: high-confidence signatures first, then the scoped virtual patches, then the general policy after a few weeks of tuning.

I wrote the full guide, with the common mistakes and how the major WAF platforms handle report versus block modes, here: Virtual patching with a WAF and a web scanner

— Kazem Mortazavi, independent network-security consultant