Plugin vulnerabilities,blocked beforeyou can update.
When a security hole is found in a WordPress plugin you use, MalCare adds a virtual patch — a firewall rule that blocks attacks on that hole — usually within hours. You stay protected until you install the official fix, even if one never comes.
Plugin vulnerabilities are attacked in hours.
Fixes take days — if they come.
A vulnerability is a security hole in a plugin’s code. Once it’s made public, attackers scan the web for sites that use that plugin, long before most owners can update.
- ~5 hafter a plugin vulnerability is made public, automated attacks on it begin.
- 12 daysis the median wait for the plugin author’s official fix.
- 46%of vulnerabilities have no fix available on the day they’re made public.
- 33%never get an official fix at all.
91% of WordPress hacks start with a plugin or theme vulnerability — and 11,334 new WordPress vulnerabilities were made public last year, up 42%. Source: MalCare incident analysis, rolling 12 months.
A virtual patch is a firewall rule
for one plugin vulnerability.
It recognizes attacks on that specific hole and blocks them before they reach the plugin. Everything else passes through as normal.
Blocks only the attack
The rule is written for one vulnerability, so customers using the same feature aren’t affected.
Nothing on your site changes
No plugin code is edited. When the official update comes, it installs normally.
Covers you until you update
Even when the plugin author never releases a fix, the patch keeps blocking.
Behind the curtain:
how one virtual patch gets built.
Our security researchers write each patch from the plugin’s actual code, not just the public warning. Here’s the process for one example.
Path traversal in file import. Anyone, without logging in, can make the plugin open files outside its upload folder.
- Official fix
- Not available yet
- Example attack
POST …/import.php · file=../../wp-config.php
Once this is public, the clock starts: automated attacks typically begin within about 5 hours.
function fb_handle_import() { $file = $_POST['file'];taken straight from the visitor include FB_UPLOAD_DIR . $file;never checked for “../”}The advisory describes the symptom. The code shows the cause: one function that trusts a file name it shouldn’t.
- In the advisory
/wp-content/plugins/form-builder-pro/import.php - Found in the code
/wp-admin/admin-ajax.php?action=fb_import - Found in the code
/wp-json/form-builder/v1/import
fb_handle_import()A patch that only watches the advisory’s example stops one route. Attackers simply use the other two.
- Patch
- VP-2481 · form-builder-pro up to 3.2.1
- Watches
- All 3 routes into the import code
- Blocks
- File names that climb out of the upload folder — “../” in any spelling or encoding
- Allows
- Normal file names, so real imports keep working
Aimed at what every version of the attack must do, rather than one example of it — so disguised and re-routed attacks are caught too.
- ~500test runs before release
- 5 / 5forms of the attack blocked
- 6 / 6kinds of real traffic still work — checkout, forms, logins, uploads, admin saves, API calls
- Tried on live sites first
- Sent to every MalCare site
- Live on yours — nothing to install
Median time from the vulnerability going public to this patch protecting your site: about 4 hours.
Faster virtual patches
that are harder to get around.
Speed decides whether a patch arrives before the attacks. Coverage decides whether it holds once they do.
Time from a vulnerability going public to protection
- MalCare~4 hours
- Nearest competitor~6 hours
- Plugin author’s official fix⟶~12 days
Median times. Scale shows the first 24 hours; automated attacks usually start around hour 5.
- 19,000+virtual patches shipped
- 3×more patches for recent vulnerabilities than the nearest competitor last week (144 vs 43)
- 2.1Mattacks blocked in the last 30 days
One vulnerability, attacked five ways
Each kind of protection was tested on its own against the same requests. Every one is good at its own job; this measures plugin attacks only.
◐ = partly or sometimes. Every MalCare patch ships with open test scripts, so you can check what it blocks yourself. Figures as of May 2026.
Virtual patches that don’t break your site. And the truth when one can’t be complete.
A patch only ships if it blocks the attack and your site still works. When an attack looks exactly like normal use, we say so and tell you to update.
- Tested against checkout, forms, logins, uploads, admin saves and API calls
- Your plugin files are never changed
- Runs on MalCare’s servers — no slowdown
- Marked “partial protection” when a full block isn’t safe
Every patch shows up
in your dashboard.
You don’t write rules or change settings. You see which plugins are vulnerable, which are already covered, and when to update.
- An alert when a plugin you use is vulnerableWith how serious it is and when it was made public.
- “Patched” means you’re already coveredOften the first thing you hear about a new vulnerability.
- Update on your scheduleOne site or all of them at once. Managing 10+ sites? WPRemote adds safe test updates and client reports.
In their words. Covered before they had to act.
I was on the beach with my family when MalCare notified me of a plugin vulnerability across 50 of my sites. With one click on my smartphone, all sites were fixed within minutes.
Paul LaceyWordPress ExpertI came looking to fix a redirect hack & the cleanup got rid of it in minutes…then I started tinkering with the dashboard. Never had to worry about hacks again.
Mark TullWebsite EssentialsI had been running iThemes, WordFence & Sucuri, but they kept getting hacked. Then I installed MalCare, which quickly found the malware and cleaned up the entire site.
Adam SilverConciergeWP · FounderVirtual patching questions, answered.
The next plugin vulnerability is coming. Be patched before the attacks start.
Set up in under 5 minutes. Existing patches apply as soon as your site connects, and new ones arrive on their own.