Virtual Patching Explained: Blocking a WordPress Vulnerability Before You Can Patch It

There is a real, uncomfortable gap between "a vulnerability is publicly disclosed" and "every affected site has actually applied the fix." Researchers disclose responsibly, plugin authors patch quickly, but the update still has to reach every installation — and on a large managed portfolio, that can take longer than the gap an opportunistic attacker needs to start scanning for the exact vulnerable pattern.

What virtual patching actually does

Virtual patching blocks the specific request pattern a known vulnerability depends on — a particular query parameter, a specific REST route, a request shape matching a known exploit — at the web server or application layer, without modifying the vulnerable plugin’s code at all. It is not a replacement for the real update; it is a temporary shield that closes the exploit window while the real fix gets tested and rolled out through the normal update process.

Why "just block everything suspicious" doesn’t work

A general-purpose web application firewall that tries to block anything that looks vaguely malicious produces a steady stream of false positives — legitimate requests blocked because they happen to resemble an attack pattern. This is a serious problem for a security tool: a false positive that blocks a real customer or a real checkout flow is itself a business-impacting failure, and it erodes trust in the tool faster than an actual missed attack does.

The narrower, safer approach

The more defensible version of virtual patching is narrow and specific: one rule, tied to one known vulnerability, matching the exact request pattern that vulnerability depends on — not a general heuristic guessing at "suspicious" traffic. A rule this specific has a much smaller blast radius if it’s ever slightly wrong, and it can be safely reviewed by a human before activation rather than auto-generated and auto-applied without oversight.

Fail open, not closed

Any virtual patching system has to handle its own failure gracefully. If a rule is malformed or the rule-checking logic itself errors, the correct behavior is to skip that rule and let the request through as normal — never to block all traffic because one rule broke. A security feature that can take down a legitimate site due to its own bug is a worse outcome than the vulnerability it was trying to mitigate.

When to actually use it

Virtual patching earns its place specifically in the gap between disclosure and your own ability to update — a known CVE on a plugin you can’t immediately update on every affected site, especially one already showing signs of active exploitation in the wild. It is a bridge, not a permanent substitute for keeping software current.

WPGuard's own virtual patching is deliberately scoped this way — hand-curated rules tied to a specific known vulnerability, never auto-generated or auto-activated without review. Read the full approach on the Security page.