The target
Plugins and themes
95% of hacked WordPress sites were hacked through a vulnerable plugin or theme.
Our firewall blocksattacks before your siteruns them.
Every request is checked before WordPress executes anything — against rules learned from attacks on 400,000+ sites, usually before the same attack ever reaches you. Zero configuration, zero load on your server.
2B+ blocked / mo/18B+ analyzed / mo/0 config
Trusted by 400,000+ sites · 120 countries
The problem
Every hack starts as a request.
Your site runs whatever the internet sends it. Attack requests look almost exactly like visitor requests — until your site runs them.
POST /wp-admin/admin-ajax.php HTTP/1.1Host: yoursite.comContent-Type: application/x-www-form-urlencodedaction=profile_save&user_id=42&nickname=sam&role= subscribera member updates their profileadministratoraccount 42 becomes an administrator152 characters identicalone field different
Your site cannot tell them apart after it runs them. The firewall tells them apart before.
The vehicle
A crafted request
The exploit rides inside an ordinary-looking request, aimed at code — not at your password.
The fix
Check every request first
A firewall checks every request before your site executes anything.
02Checked before your site runs a single line.
Every request passes through the firewall first. Attacks get a 403. Everything else proceeds untouched.
- 2.1Inspected firstEvery request is judged before WordPress executes anything.
- 2.2Three checksWordPress-specific rules, known attack signatures, and network behavior signals.
- 2.3Nothing to clean upA blocked attack costs your site nothing. It never ran.
Coverage
Built only for WordPress. All ten OWASP threat classes covered.
Generic WAFs run generic rules that let WordPress-specific attacks through. MalCare's firewall does only WordPress, so its rules match how WordPress is actually attacked.
OWASP Top 10 + WordPress-specific protection
Every OWASP threat class, plus the WordPress attack patterns generic rules never cover.
- InjectionSQL, command, and code injection
- Broken access controlPrivilege and path abuse
- Cross-site scriptingStored and reflected XSS
- Insecure designAbusable flows and logic
- Security misconfigurationExposed surfaces
- Vulnerable componentsPlugin and theme exploits
- Authentication failuresCredential attacks
- Integrity failuresTampered updates and data
- Logging & monitoring gapsSecurity events kept on the record
- Server-side request forgerySSRF patterns
Not on the list
WordPress-specific rulesThe attack patterns generic WAFs do not describe
04Part of your site. There is no way around it.
A cloud WAF stands in front of your site. MalCare's firewall is inside the only request path there is.
- 4.1Nothing to bypassCloud WAFs can be skipped by finding the real server address behind them. MalCare has no separate address to find.
- 4.2Every request goes through itThe firewall runs as part of WordPress itself. A request cannot reach your site without being checked.
- 4.3No DNS changesNothing to re-route and no setup that can silently break.
Performance
The heavy lifting runs on our servers. Not yours.
Your server does one lightweight job: enforce verdicts. Rule building, threat correlation, and bot conviction run on MalCare's infrastructure.
Up to 70% lighter server load after moving to MalCare — bot floods are turned away before they reach your server. The only security plugin that makes your site faster.
The family
One core firewall. Five specialist layers on top.
The core firewall checks every request. Five specialist layers extend it — same network, same dashboard, all included.
Specialist
Vulnerability Shield
Patches a plugin flaw the day it is disclosed — before you can update.
Explore shielding →Specialist
Atomic Security
Site-specific rules for flaws nobody has found yet.
Explore Atomic Security →Specialist
Login Protection
Limits, captcha, and built-in 2FA on the login form and XML-RPC.
Explore login protection →You configure nothing.
It never blocks a customer.
The firewall reads your site and sets itself up when you connect. After that, rules arrive on their own.
- Auto-configures on connect — no rules to write, ever
- Maintenance: none — updates arrive from the network
- False positives designed out — customers and good bots pass
- Every block on the record — open the firewall screen anytime
What a firewall usually asks forYour part
- Rule sets to enable—
- Sensitivity to tune—
- Allowlists to maintain—
- Block duration to set—
- Custom rules to write—
Your part: nothing.Customers, search crawlers, uptime monitors and your integrations are recognised — no exceptions to add.Customers, crawlers, monitors and integrations are recognised.
In their words. Hundreds of attacks, quietly stopped.
Rated 5 out of 5
MalCare sends few security notifications, so one day out of curiosity I checked their firewall section. I was pleasantly surprised that hundreds of attacks were being quietly thwarted! I really like this 'strong & silent' protection.
Jo WalthamCallia WebRated 5 out of 5
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 expertRated 5 out of 5
I 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 SilverFounder · ConciergeWPComparing firewalls? Ask a person.
A security expert will tell you exactly what MalCare blocks that your current setup does not. No obligation.
Common questions, answered.
Yes. Updates close known holes on your schedule; attacks arrive as requests on theirs — and 95% of WordPress hacks exploit plugin and theme vulnerabilities, not passwords. The firewall covers the gap between the two, in real time.
Three ways. WAFs such as Cloudflare have generic rules which allow most attacks to pass through; MalCare's rules are built only for WordPress. A cloud WAF sits in front of your site and can be bypassed by finding the origin address; MalCare is part of the site, in the only request path there is. And there is nothing to configure — it tunes itself.
No. Enforcement on your site is lightweight — MalCare servers do all the heavy lifting so your site will only be serving customers. Because the firewall turns away bot floods, sites typically get lighter when it goes on, by up to 70%.
There is no separate address to find and no seam to slip through — the firewall is integrated with your site, so every request that reaches WordPress passes through it by construction.
Preventing false positives is a design goal — losing a customer to your own firewall costs more than most attacks. Good bots, APIs, and integrations are recognized and allowed too.
The OWASP Top 10 threat classes, WordPress-specific exploit patterns against vulnerable plugins and themes, bot floods, and login attacks — plus virtual patching, site-specific atomic rules, geoblocking, and login protection.
No. The firewall auto-configures when you connect your site, and rules update continuously from the 400,000-site network. There is nothing to tune, ever.
Included — along with every specialist layer on this page. One plugin, one dashboard, every plan.
Put a real firewall between your site and the internet.
Real-time, WordPress-only rules. Part of your site. Zero configuration, zero added load.
Auto-configures on connect/No way around it/Included in every plan