When a WordPress plugin vulnerability goes public, clients usually ask us one thing first: does the firewall already cover it? The answer depends on the kind of vulnerability.
Virtual patching means a web application firewall (WAF) rule written to block the known exploit for one specific flaw. It can protect a site within hours of disclosure, often before the plugin developer ships a fix. It is weakest against the vulnerability class attackers exploited most in 2025, and it cannot reach code or malware already on the server.
At Curious Minds Media we use virtual patching to cover the gap between disclosure and a tested update, and we plan the rest of each site’s security around what a firewall cannot do.
What is virtual patching?
Virtual patching is a firewall rule that detects and blocks requests matching the exploit for a known vulnerability, without changing the vulnerable plugin or theme code. The rule targets a specific attack path, such as a particular parameter sent to a particular plugin endpoint. The vulnerable code stays on the server until someone updates or removes it.
OWASP’s definition is careful on this point. A virtual patch reduces exposure only for the traffic the firewall inspects and the attack variants its rules recognize, and the underlying vulnerability stays in place.
These rules can run in three places.
An edge WAF, such as Cloudflare, inspects traffic before it reaches the hosting server.
A host-level WAF runs on the server itself.
An application-level firewall, such as Wordfence, runs inside WordPress, where it can see session data and the role of the logged-in account.
That last capability matters a great deal for WordPress, as the sections below explain.
Why does the gap between disclosure and a fix matter?
Patchstack’s State of WordPress Security in 2026 report counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025. That’s a 42 percent increase over 2024, and 91 percent of them were in plugins. For 46 percent of those vulnerabilities, the developer had not released a fix by the time of public disclosure.
Exploitation moves faster than most update cycles. Patchstack found that roughly half of high-impact vulnerabilities were exploited within 24 hours. For the most heavily targeted ones, the weighted median time to first exploit was 5 hours.
For close to half of newly disclosed vulnerabilities, there is no update to install on the day the flaw becomes public. The most attractive targets come under attack within hours. A virtual patching rule deployed at disclosure is often the only control in place during that window, which is why we consider it worth having on every business-critical site.
What does a WAF stop well?
Firewalls are effective against requests that look malicious on their face. SQL injection strings, directory traversal sequences, and script tags submitted in fields meant for plain text all carry patterns a rule can match.
OWASP describes virtual patching as best suited to injection-type flaws. Patchstack’s testing likewise found that hosting-level WAFs did somewhat better against generic vulnerabilities than WordPress-specific ones.
At the edge, a WAF also absorbs bot traffic and brute force attempts against login pages before they reach the origin server. We configure that filtering as part of managed hosting for the sites in our care, and it does useful work every day.
What does a WAF miss?
Broken access control and privilege escalation
Broken access control was the most exploited vulnerability class in WordPress in 2025, according to Patchstack. It is also the class traditional WAFs have the most trouble defending against.
In WordPress terms, a plugin registers an AJAX action or REST API route but skips the capability check or nonce verification that should gate it. A subscriber-level account, and sometimes an anonymous visitor, can then call a function meant for administrators.
The exploit request carries no injected code and no unusual characters. Patchstack notes that these exploits look like ordinary authenticated traffic, with no injection pattern for a rule to catch.
Patchstack measured the effect in two penetration tests against hosting providers in 2025. Traditional defenses blocked 12 percent of WordPress-specific attacks in the first study. In the second, broader study, they blocked 26 percent of all attacks. In the first study, one host’s Cloudflare WAF blocked 4 of the 11 plugin exploits Patchstack ran.
Patchstack sells application-layer virtual patching, so its tests are not neutral, and we treat the exact percentages as directional. The mechanics hold regardless of who runs the test. A rule that inspects only the request cannot tell whether the account sending it has permission to do what it asks.
Problems already inside the site
Stolen administrator credentials produce legitimate logins, and a firewall has no basis for blocking them. Malware already on the server keeps running whether or not new requests are filtered.
Monarx data in the same Patchstack report describes the Lock360 malware family. It runs in server memory and reinfects files such as index.php and .htaccess as soon as they are restored. The report also describes attacks that inject malicious snippets into legitimate core, plugin, and theme files. No inbound firewall rule addresses either problem.
Traffic that never reaches the firewall
An edge WAF protects only the requests routed through it. If a site’s origin IP address is exposed, an attacker can send requests straight to the hosting server and skip edge inspection entirely.
Cloudflare’s documentation describes additional steps for protecting the origin server, and they require deliberate configuration. This is one reason we pair edge filtering with protection on the server and inside WordPress.
Where each layer of protection applies
The breakdown below summarizes how each layer handles the threats described above. It draws on the Patchstack and OWASP findings cited in this article and on our experience maintaining WordPress sites. It is a planning guide, and individual configurations vary.
Injection payloads (SQL injection, XSS, directory traversal)
Edge WAFs such as Cloudflare often block these when a signature matches. Host-level WAFs often block them too, though results vary by configuration. Application-level firewalls such as Wordfence often block them as well. A tested update removes the flaw.
Broken access control and privilege escalation
Edge and host-level WAFs handle these inconsistently. An application-level firewall blocks them only when it has a rule written for that specific vulnerability. A tested update removes the flaw.
Logins with stolen credentials
No firewall layer blocks these. Edge, host-level, and application-level rules all see a valid login. Two-factor authentication and least privilege are what address this risk, and an update does not apply.
Malware already on the server
Edge and host-level WAFs do not address it. An application-level tool’s scanning may detect it, but cleanup is still required. An update does not remove existing malware.
Requests sent directly to an exposed origin IP
An edge WAF never inspects these requests. Host-level and application-level firewalls do, and a tested update removes the flaw.
Why do virtual patches fail?
Virtual patches fail in a few predictable ways, and each one appears in published research or vendor documentation.
A rule written too narrowly misses variations of the attack. OWASP warns against exploit-specific virtual patches that block only the exact payload from a proof of concept, since small changes to the payload can get past them.
MalCare documented a case where a customer site had a vulnerability-specific virtual patch in place and was compromised anyway. The rule checked for a value in fields where that value would never appear. The vendor corrected the rule once the flaw was reported.
A rule written too broadly breaks legitimate functionality. OWASP notes that a virtual patch can block valid transactions even though the application code is unchanged. MalCare has seen rules for some vulnerabilities end up blocking legitimate requests from the affected plugin itself. A rule that breaks a checkout or a form submission tends to get loosened or switched off, often without anyone recording that the protection is gone.
Rule delivery depends on the vendor and the plan. Wordfence Free receives firewall rules and malware signatures on a 30-day delay, while paid tiers get them in real time.
Measured against a 5-hour weighted median to first exploit, a rule that arrives a month later covers very little of the window it was written for.
Rules depend on configuration that can change quietly. A host migration or a change to a Cloudflare plan can remove protection that nobody on the WordPress side knew existed.
Why should a virtual patch stay temporary?
The longer a firewall rule stands in for an update, the more these risks compound. Patchstack found that only four of the ten vulnerabilities attackers targeted most in 2025 were published that year. Attackers kept going after older flaws because outdated versions of those plugins were still installed on the sites Patchstack monitors.
Premium plugins deserve particular attention. Patchstack reports that premium WordPress components had three times as many known exploited vulnerabilities as free ones. It also notes that their code gets less scrutiny because researchers have a harder time accessing it. Virtual patching rules depend on published research, so components that receive less research also receive fewer rules.
How we use virtual patching on the sites we maintain
Curious Minds Media has built and maintained websites since 2004, and every engineer doing that work is an in-house, US-based member of our team. We treat the firewall as one layer among several.
Our firewall stack includes MalCare, Wordfence, and WP Engine’s platform protections. In July, WordPress released version 7.0.2 to fix a vulnerability chain researchers named wp2shell. CVE-2026-63030, a route-confusion flaw in the REST API batch endpoint, let an unauthenticated request reach CVE-2026-60137, a SQL injection in WP_Query, and together they allowed remote code execution on WordPress 6.9 and 7.0 sites. Exploitation attempts were reported the same evening the patch shipped.
Our firewall layers mitigated exposure on the sites in our care within the first day, and and we checked our sites with Searchlight Cyber’s public wp2shell checker. The chain depends on a SQL injection, the type of attack firewalls match most reliably.
We still applied the core update during maintenance and checked the results, because some automatic core upgrades from our host reported both success and failure for the same environments.
Virtual patch status also decides the order of our work. When attackers began actively exploiting a critical file upload vulnerability in Elementor Pro in September, our firewall vendor confirmed a virtual patch was already in place across the sites it protects.
We moved first on client sites outside that coverage and brought the rest current during scheduled maintenance. We apply the same triage to every disclosure. A vulnerability with a virtual patch in place drops in priority, and a site that cannot be updated, or a vulnerability with no patch available, moves to the top.
Plugin and theme updates on our maintenance plans are reviewed for compatibility and tested in staging where possible before they reach production. That process keeps the window a virtual patch has to cover as short as we can make it.
Access control gets its own attention because firewalls handle it worst. After a repeat compromise on a client site earlier this year, we made two-factor authentication and disabled in-dashboard file editing mandatory on every site we maintain. We also apply the principle of least privilege to administrator access.
We run vulnerability scans after maintenance windows, because repository auto-updates do not reliably cover plugins that have been disconnected from the repository or are no longer supported. When a vulnerable plugin has no fix coming, we keep the firewall rule in place only until we have replaced or removed the plugin.
“Any site not behind a WAF that’s actively blocking this is vulnerable. It allows anyone who knows the URL of a site to create an admin account.” - Andrew Engstrom, WordPress Practice Lead, Curious Minds Media
What should you ask about your own firewall?
If your site depends on a firewall for security, a few questions will tell you how much protection you have. Ask which layer the firewall runs at, whether it receives rules for WordPress plugin vulnerabilities specifically or only generic attack signatures, and whether your plan delivers those rules in real time or on a delay.
Ask what happens on your site when a plugin vulnerability is disclosed before the developer has released a fix, and who is responsible for removing or replacing that plugin if a fix never arrives. Ask how administrator accounts are protected, since a firewall cannot tell an attacker using valid credentials apart from your own team.
Clear answers to those questions tell you more than the name of the security product on your hosting invoice.
Virtual patching belongs on every business-critical WordPress site. It covers the hours and days between disclosure and a tested update, and it handles attacks with recognizable signatures well. The vulnerable code still has to be updated or removed, and access control still has to be enforced inside WordPress, because those parts of the problem sit outside what a firewall can see.
Our WordPress maintenance and support plans cover updates, monitoring, and hardening, and our managed hosting covers edge and server-level filtering.
