Most firewalls build patches from public alerts — they block the obvious attacks. Vulnerability Shield builds every patch from the actual vulnerable code, so it blocks the widest range of attacks, including the ones others miss.
$ wp plugin install malcare-security — protected in under 5 minutes
When a plugin has a security flaw, the official fix can take days — sometimes it never comes. That waiting period is when sites get hacked. Vulnerability Shield stands in front of the flaw the moment it's known, with zero effort on your part.
Representative timeline, from network medians — disclosure → mass exploitation ~5 h · official patch ~12 d (Figs 2–3). Identical attack replay against both timelines; the only variable is the Shield.
Think of it as a bodyguard at the door while a stronger lock is on the way. The lock is the real fix. We make sure nobody gets in while you wait for it.
New flaws are disclosed every week and mass-exploited within hours. "Just keep everything updated" is no longer a defense — it's a race you can't win manually.
average from public disclosure to mass exploitation — shrinking as attackers automate with AI
of vulnerabilities have no patch available the day they go public — there is nothing to update to
never receive a developer patch at all — waiting for a fix that isn't coming
median wait for an official plugin patch after disclosure
of WordPress hacks start with a plugin or theme vulnerability. Staying exposed — even for a day — is the single biggest risk your site carries.source: malcare incident analysis, rolling 12 months
Attack volume against a freshly disclosed vulnerability — and where the Shield cuts it off.
97% of the exposure window eliminated vs waiting for the official patch — and 30% faster than the nearest competitor (~4h vs ~6h median).
A single unprotected flaw rarely stays a single problem. The chain reaction, as site owners actually experience it.
Spam pages and redirects Google sees first.
~6 mo to recover"Deceptive site ahead" stops visitors cold.
−80% trafficA tampered checkout quietly bleeds orders.
hidden ~3 moRemoval, host suspension, downtime, refunds.
$500–$3,000Panic-updating breaks checkout and bookings.
lost trustA third of flaws never get an official patch.
33% unpatchedTake one plugin flaw, in every form an attacker actually sends it, and test each defense on its own. Host security and CDN firewalls are excellent at what they're built for — plugin exploits are not that.
Each defense tested alone against the same request set — ◐ = partial or sometimes. Host security and CDN firewalls remain excellent at what they're built for; this benchmark measures one thing only: WordPress plugin exploits, in the forms attackers actually send them.
Kinsta · WP Engine · SiteGround — keeps the server stable and online. It protects infrastructure, not plugin code, so every form of the exploit passes.
BLOCKS 0 OF 5Cloudflare · Sucuri · Imunify360 — great against bots, brute force, bad IPs. But plugin exploits look like normal requests; at best a generic signature catches the published form.
BLOCKS ~1 OF 5Wordfence · Solid · Patchstack — fast to react, but a rule built from the public advisory matches the published form. Re-encode it, swap the method, or take another route, and it walks past.
BLOCKS ~2 OF 5MalCare — the rule is built from the vulnerable code itself, so it guards what every form of the attack has in common: the dangerous operation it must reach.
BLOCKS 5 OF 5Each of these is useful. None of them reads the vulnerable code the way an attacker does. That's the gap Vulnerability Shield was built to close.
A public alert shows one way to trigger a flaw. Most firewalls copy their rule from it — so they block that one example, while the same attack slips through in a different shape.
We read the vulnerable code itself and guard the dangerous operation inside it. Every shape of the attack has to reach that operation — so every shape hits the rule.
Coverage is a width. Their rule is as wide as the example in the alert. Ours is as wide as the flaw.
Five identical requests, dropped on both rules — four shapes of one flaw, plus a real visitor. A rule copied from the alert is exactly as wide as the alert. A rule built from the code is as wide as the flaw — and lets the visitor straight through.
No guesswork, no copy-pasting advisories. The exact process every patch passes before it touches your site.
Not just the published example — the actual vulnerable behavior.
Checkout, login, uploads, forms, comments, API calls keep working.
Reordered parameters, re-encoded payloads, method changes, alternate routes.
A CVE is a rumor. We turn it into a target record: exactly which plugin, versions, endpoints, and permissions are at risk.
Advisories can name the wrong parameter, miss a second entry point, or understate the required role. We build a precise record: affected component, vulnerable version range, fixing version, vulnerability class, auth/role required, and every endpoint, action, parameter, route, or file involved. A patch has to protect the whole affected version range, not the one build in a public example.
FIG. 7.1 — target extraction
We download the real plugin code. The vendor's fix is a map: the diff shows exactly where the danger lives.
If the fix adds a nonce check, tightens a capability, sanitizes a value, or blocks a file type — that tells us what behavior the vendor decided to reject. And because plugins share code paths, reading the source is how we avoid guarding the front door while the side door stays open.
function handle_import( $req ) {
- $file = $req['file'];
+ if ( ! current_user_can('manage_options') )
+ return new WP_Error('forbidden');
+ $file = sanitize_file_name( $req['file'] );
+ if ( is_executable_type($file) ) return;
process_import( $file ); // ← danger
}FIG. 7.2 — the diff reveals the invariant our rule must guard
We follow attacker-controlled input through routing, permission checks, and normalization — to the operation that does the damage.
The dangerous operation could be a file write, option update, role change, SQL query, code-execution path, or stored-XSS sink. Tracing separates what the attack needs from what the proof-of-concept happens to show — and surfaces sibling vulnerabilities: other AJAX actions using the same unsafe helper, other routes reaching the same function.
FIG. 7.3 — exploit trace
Strong enough to catch every variant, precise enough to never block a real customer — one clear defensive job per rule.
Strong: catches reordered params, changed methods, new encodings, alternate routes. Precise: blocks the malicious shape while allowing the real feature — block the executable upload, allow the image. Simple: one defensive job, so it's reviewable. Consolidated: shared vulnerable behavior gets one coherent defense, not scattered near-duplicates.
FIG. 7.4 — design criteria
A structured second pass catches wrong assumptions while they're still cheap to fix. A rule that fails here goes back to design.
We verify supported firewall operations, that every clause has a purpose, that version scope matches the source analysis, and that entry points match the exploit map. Wrong assumptions — subscriber-level when the bug needs an admin, REST-only when it's also reachable via AJAX, raw-string match when the value is dangerous only after decoding — are exactly what this stage exists to catch.
FIG. 7.5 — paper review
We reproduce the exploit and block it. Then we replay messy, real-world WordPress traffic. Then we attack the rule itself.
Checkout submissions, contact forms, logins, image uploads, comments, post saves, REST calls, admin changes — replayed against the rule. If any legitimate flow breaks, the rule goes back. Then come the evasions: re-encoded payloads, reordered parameters, swapped methods, aliased URLs, values dangerous only after normalization. The loop runs until it passes cleanly — or we conclude safe protection is only partial, and say so.
FIG. 7.6 — proof under fire
Final checks run in the same firewall path that will protect your site — canary first, watched signals, then the whole network.
The rule enters MalCare's deployment system and is validated in controlled environments: exploit still blocked, legitimate traffic still passes, version scoping applies correctly, behavior stays consistent in the live firewall path, rollout signals watched before expansion. Only then does it become the background protection a site owner never has to think about.
FIG. 7.7 — staged deployment
pentests per patch to eliminate false positives and plugin conflicts before it ever reaches you.
A green badge should mean something specific. For us it means: exploit path analyzed, scope identified, real attack reproduced and blocked, ordinary traffic allowed, bypasses tested, rollout validated.
Sometimes a malicious request genuinely can't be told apart from legitimate traffic at the firewall layer. When that happens, we don't ship a sloppy rule and slap a green check on it. We flag it as partial protection and point you to the update path.
Honesty is the productCoverage and speed against the field, from the live network.
3× the protection coverage, week after week
5× more attack surface closed
axis compressed — the real gap is 70× wider
Point-in-time figures as of May 2026 · refreshed monthly
What you actually see: flaws detected, patches applied, updates de-risked — no rules to write, no settings to tune.
Scored live from plugin release history, code-change size, and conflict reports across the network. Protection doesn't depend on the score — the score only tells you when the permanent fix is safe to apply.
New flaws in your plugins appear within hours of disclosure, with risk details.
Tested patches apply automatically — you just see the stamp. When protection is partial, we say so.
A real-time score from multiple sources tells you when it's safe to update.
Test the official update on instant staging before rollout. No surprises.
Blocking the published exploit is the easy part. An attacker working the standard evasion playbook against one of our patches:
Flaws can be exploited for months before they're ever disclosed. Three more layers — included free — cover the rest of the timeline.
A firewall layer that adapts to your individual site's structure, proactively hardening the assets attackers target most.
INCLUDED FREEPowered by a global network of 400,000+ sites: a new threat anywhere becomes a live rule everywhere, instantly.
INCLUDED FREERuns automatically every day, off-server with zero site load, to catch anything that slips through.
INCLUDED FREEAdd them all to your MalCare dashboard and manage vulnerabilities, updates, firewall, and security centrally.
Our agency suite with sandbox updates, backups, client reports, and better bulk pricing across your whole portfolio.
100,000+ sites · 30+ countries · single-site owners to agencies running hundreds
Under 5 minutes — install, connect, done. Patching starts after the first sync.
No. It runs alongside Cloudflare, host firewalls, and other plugins as a complementary WordPress-specific layer — not a replacement for your broader perimeter.
Every patch is tested against real traffic — checkout, forms, logins, uploads, admin saves, API calls. If any legitimate behavior breaks, the patch goes back. A security rule should never become an outage.
No. Scanning runs off-server on our infrastructure; the patching layer adds undetectable milliseconds. Your site performance is unaffected.
Yes. Most customers run us alongside their existing tools specifically for the source-built patching layer those tools don't provide.
We tell you. We flag it as partial protection and recommend the update path — no fake green checkmarks.
Any host. If you migrate, your protection migrates with you.
Yes. Virtual patching buys safe time; the update is the permanent fix. We'll remind you when it's ready.
Source-built patches, honest protection, zero hassle. Start free — your site is protected within minutes.
No credit card · under 5-minute setup · works on any host