WEB-ART Creative Design

Web-Art Login Shield with reCAPTCHA is a focused security plugin that protects WordPress authentication, Elementor Login widgets and Elementor Forms against automated attacks.
It strengthens wp-login.php, Elementor Login and Elementor Forms by integrating Google reCAPTCHA v2 verification and optional IP-based rate limiting, without replacing or modifying WordPress core authentication logic.
The plugin is intentionally lightweight and transparent: 
– no ads 
– no telemetry or analytics sent to the author 
– no third-party dashboards provided by the plugin 
– no all-in-one security suite overhead
All login protection modules (reCAPTCHA, Login Protect, Advanced login URL) are opt-in and disabled by default.
Additionally, the plugin can apply a small XML-RPC hardening rule-set (disables a few high-risk XML-RPC methods) to reduce common abuse vectors. This does not disable XML-RPC completely. XML-RPC hardening is applied only when Login Protect is enabled and “Protect XML-RPC logins” is enabled.
Each module (reCAPTCHA, Login Protect, Advanced login URL) can be enabled independently. Elementor reCAPTCHA options require reCAPTCHA to be configured and verified.
<h3>Key Features</h3>
<h4>reCAPTCHA v2 integration</h4>
<ul>
<li>reCAPTCHA v2 checkbox for wp-login.php (when enabled and IP is not allowlisted)</li>
<li>server-side token verification for WordPress login and Elementor Forms validation</li>
<li>reCAPTCHA must be verified before enabling protection</li>
</ul>
<h4>Elementor reCAPTCHA options</h4>
<ul>
<li>automatic frontend injection for Elementor Login widgets (when enabled)</li>
<li>optional frontend injection for Elementor Forms (Elementor Pro) (when enabled)</li>
<li>Custom Alignment: Ability to set Left, Center, or Right alignment for reCAPTCHA in both Elementor Login and Elementor Forms directly from plugin settings.</li>
<li>Elementor frontend scripts inject reCAPTCHA only when they detect relevant widgets/forms in the DOM (supports dynamically loaded content, popups, AJAX, etc.)</li>
<li>Google reCAPTCHA scripts are not loaded for allowlisted IPs</li>
</ul>
<h4>Whitelist IPs (reCAPTCHA)</h4>
<ul>
<li>reCAPTCHA IP allowlist (allowlisted IPs bypass reCAPTCHA checks on wp-login.php, Elementor Login and Elementor Forms; Login Protect may still apply)</li>
<li>reCAPTCHA allowlist accepts one entry per line (exact IP match only)</li>
<li>optional note format supported: IP | reason (reason is ignored for matching)</li>
</ul>
<h4>Login Protect (IP-based lockouts)</h4>
<ul>
<li>failed login attempt counting per IP address</li>
<li>timed lockouts after a configurable threshold</li>
<li>blocked IP list (lockouts expire automatically after the configured lockout time)</li>
<li>recent security event log (stored locally)</li>
<li>wp-login.php lockout UX: countdown notice and temporary submit blocking during an active lockout</li>
<li>Login Protect is independent of reCAPTCHA (can be enabled and used without reCAPTCHA enabled)</li>
<li>three practical protection modes:
<ul>
<li>MODE 1 – reCAPTCHA only</li>
<li>MODE 2 – reCAPTCHA + Login Protect</li>
<li>MODE 3 – Login Protect only</li>
</ul>
</li>
</ul>
<h4>Trusted IPs (Login Protect)</h4>
<ul>
<li>separate allowlists for reCAPTCHA and Login Protect (exact IP match only)</li>
<li>Login Protect allowlist accepts one entry per line (exact IP match only)</li>
<li>optional note format supported: IP | reason (reason is ignored for matching)</li>
</ul>
<h4>REST API and XML-RPC protection (optional)</h4>
<ul>
<li>optional protection for authentication attempts via XML-RPC and REST API (applies only when the corresponding checkbox is enabled; Login Protect must be enabled)</li>
</ul>
<h4>XML-RPC hardening (optional)</h4>
<ul>
<li>optionally disables a small set of high-risk XML-RPC methods commonly abused by attackers:
<ul>
<li>pingback.ping</li>
<li>pingback.extensions.getPingbacks</li>
<li>system.multicall</li>
</ul>
</li>
<li>XML-RPC hardening is applied only when Login Protect is enabled and “Protect XML-RPC logins” is enabled 
This reduces abuse without disabling XML-RPC entirely.</li>
</ul>
<h4>Advanced login URL (optional)</h4>
<ul>
<li>single toggle enables Advanced login behavior</li>
<li>custom login endpoint (rewrites requests to the standard WordPress login handler without altering core authentication logic)</li>
<li>when Advanced is enabled, wp-login.php and wp-admin are protected for non-authenticated visitors</li>
<li>protection behavior is configured via two required fields:
<ul>
<li>Custom login URL slug (example: “secure-login-1234”)</li>
<li>Default redirect slug (recommended: “404” to display the active theme’s 404 page)</li>
</ul>
</li>
<li>both fields are required when Advanced is enabled (saving is blocked if any field is empty)</li>
<li>if fields are empty when enabling Advanced, the plugin auto-generates a secure random login slug and sets the redirect slug to the recommended default</li>
<li>protection applies only to non-authenticated users (logged-in users can still access wp-admin and wp-login.php)</li>
<li>safe fallback handling to avoid logout loops (wp-login.php?action=logout remains accessible)</li>
</ul>
<h4>IP Blocking (Site-wide)</h4>
<ul>
<li>single toggle enables site-wide IP blocking</li>
<li>permanently blocks selected IP addresses from accessing the entire site (returns HTTP 403)</li>
<li>blocklist accepts one entry per line (exact IP match only)</li>
<li>optional note format supported: IP | reason (reason is ignored for matching)</li>
<li>recommended use cases: persistent abuse, scraping, hostile bots, repeated attacks not covered by login-only protection</li>
<li>warning: do not add your own IP address unless you have alternative access (hosting panel / WP-CLI / database access) to remove the entry</li>
</ul>
<h3>Technical Design Principles</h3>
<ul>
<li>
Fail-closed security model (scoped) 
If reCAPTCHA verification cannot be completed and reCAPTCHA protection is enabled for the given login or form, the request is rejected to reduce the risk of automated bypass. 
Administrators can always regain access by disabling the feature in plugin settings or by deactivating the plugin via hosting or FTP.
</li>
<li>
Non-intrusive defaults 
Login protection modules remain disabled until explicitly enabled by an administrator.
</li>
<li>
Conflict awareness 
If another plugin injects reCAPTCHA into login or form flows, it should be disabled to avoid duplicate widgets or verification conflicts.
</li>
<li>
Emergency config kill-switches (wp-config.php) 
For recovery scenarios (e.g. accidental lockouts), selected modules can be force-disabled via wp-config.php constants. This does not bypass security rules; it disables the module logic before it runs. Remove the constant to restore normal behavior.
</li>
</ul>
<h3>External Services</h3>
This plugin integrates with Google reCAPTCHA v2, an external service provided by Google LLC.
reCAPTCHA features are disabled by default. The plugin does not load reCAPTCHA scripts or send verification requests unless an administrator enables reCAPTCHA protection and/or uses the “Verify reCAPTCHA” test in the plugin settings.
Google’s reCAPTCHA JavaScript (https://www.google.com/recaptcha/api.js) may be loaded on: 
– wp-login.php (when reCAPTCHA is enabled and the visitor IP is not allowlisted) 
– the frontend (when Elementor Login protection is enabled and a non-allowlisted visitor loads the page; injection occurs only if Elementor Login widgets are detected in the DOM) 
– the frontend (when Elementor Forms protection is enabled and a non-allowlisted visitor loads the page; injection occurs only for Elementor Forms) 
– the plugin settings page only when an administrator runs the “Verify reCAPTCHA” test (if provided in the UI)
When a visitor (or admin during verification) completes the reCAPTCHA challenge: 
– a verification token (g-recaptcha-response) is generated in the browser 
– during server-side verification on your website, the token and the configured Secret Key are sent to: 
 https://www.google.com/recaptcha/api/siteverify 
– the visitor’s IP address is sent to Google as the remoteip parameter when it is available on the server
The plugin sends the g-recaptcha-response token to Google only when the protected form is submitted (login attempt / form submission) or when an administrator runs the “Verify reCAPTCHA” test. 
The plugin does not send usernames, passwords, email addresses, or any form field contents to Google – only the reCAPTCHA token, the configured Secret Key, and the visitor IP address (remoteip) when available.
The plugin does not store or process any data returned by Google beyond the verification result, and it does not send any telemetry, analytics, or usage data to the plugin author.
Note: Google reCAPTCHA may set cookies and collect additional device and usage data in the visitor’s browser, as described in Google’s privacy policy and terms. Site owners are responsible for disclosing this in their site privacy policy and obtaining consent where required by applicable law.
Google privacy policies apply: 
– https://policies.google.com/privacy 
– https://policies.google.com/terms
<h3>Privacy</h3>
This plugin does not send telemetry, analytics or usage data to the plugin author or any third party.
Local data stored by the plugin (for security purposes only): 
– IP addresses related to login attempts / lockouts (Login Protect) 
– timestamps of failed attempts and lockouts 
– last username associated with a locked IP (Login Protect) 
– recent security event log entries (the plugin stores up to the last 30 events; entries rotate automatically) 
– last reCAPTCHA configuration or HTTP error (for admin diagnostics) 
– permanent site-wide IP blocklist entries (optional notes stored; notes are not used for matching)
Data retention: 
– security event log keeps only the most recent entries (up to 30; automatic rotation) 
– Login Protect state is stored locally and is automatically pruned (e.g. stale non-locked entries are removed over time and the list is capped) 
– permanent site-wide IP blocklist entries are retained until removed by an administrator 
– plugin data can be removed during uninstall if the uninstall cleanup option is enabled
All data is stored locally in the WordPress database and is used solely to enforce security rules and display administrative information.
<h3>Legal</h3>
reCAPTCHA is a trademark of Google LLC. 
Elementor is a trademark of Elementor Ltd. 
This plugin is not affiliated with, endorsed by, or sponsored by Google LLC or Elementor Ltd.

Web-Art Login Shield with reCAPTCHA

Protect WordPress logins and Elementor Login/Forms using Google reCAPTCHA v2 and optional IP-based lockouts.

Freemius

invisnet

<a href="http://www.fail2ban.org/?utm_source=wordpress.org&utm_medium=readme&utm_campaign=wp-fail2ban-premium-5.4.1" rel="nofollow ugc">fail2ban</a> is one of the simplest and most effective security measures you can implement to protect your WordPress site.
WP fail2ban provides the link between WordPress and <code>fail2ban</code>:
<pre><code>Oct 17 20:59:54 foobar wordpress(www.example.com)[1234]: Authentication failure for admin from 192.168.0.1
Oct 17 21:00:00 foobar wordpress(www.example.com)[2345]: Accepted password for admin from 192.168.0.1
</code></pre>
WPf2b comes with three <code>fail2ban</code> filters: <code>wordpress-hard.conf</code>, <code>wordpress-soft.conf</code>, and <code>wordpress-extra.conf</code>. These are designed to allow a split between immediate banning (hard) and the traditional more graceful approach (soft), with extra rules for custom configurations.
<h4>Features</h4>
<ul>
<li>
Failed Login Attempts 
The very first feature of WPf2b: logging failed login attempts so the IP can be banned. Just as useful today as it was then.
</li>
<li>
Block User Enumeration 
One of the most common precursors to a password-guessing brute force attack is <a href="https://wp-fail2ban.com/features/block-user-enumeration/?utm_source=wordpress.org&utm_medium=readme&utm_campaign=wp-fail2ban-premium-5.4.1" rel="nofollow ugc">user enumeration</a>. WPf2b can block it, stopping the attack before it starts.
</li>
<li>
Block username logins 
Sometimes it’s not possible to block user enumeration (for example, if your theme provides Author profiles). WPf2b can require users to login with their email address instead of their username.
</li>
<li>
Blocking Users 
Anther of the older WPf2b features: the login process can be aborted for specified usernames. 
Say a bot collected your site’s usernames before you blocked user enumeration. Once you’ve changed all the usernames, add the old ones to the list; anything using them will trigger a “hard” fail.
</li>
<li>
Empty Username Login Attempts 
Some bots will try to login without a username; harmless, but annoying. These attempts are logged as a “soft” fail so the more persistent bots will be banned.
</li>
<li>
Spam 
WPf2b will log a spammer’s IP address as a “hard” fail when their comment is marked as spam; the Premium version will also log the IP when Akismet discards “obvious” spam.
</li>
<li>
Attempted Comments 
Some spam bots try to comment on everything, even things that aren’t there. WPf2b detects these and logs them as a “hard” fail.
</li>
<li>
Pingbacks 
Pingbacks are a great feature, but they can be abused to attack the rest of the WWW. Rather than disable them completely, WPf2b effectively rate-limits potential attackers by logging the IP address as a “soft” fail.
</li>
<li>
Block XML‑RPC Requests [Premium] 
The only reason most sites need XML‑RPC (other than Pingbacks) is for Jetpack; WPf2b Premium can block XML‑RPC while allowing Jetpack and/or Pingbacks.
</li>
<li>
Block Countries [Premium] 
Sometimes you just need a bigger hammer – if you’re seeing nothing but attacks from some countries, block them!
</li>
<li>
Cloudflare and Proxy Servers 
WPf2b will work with <a href="https://wp-fail2ban.com/features/cloudflare-and-proxy-servers/?utm_source=wordpress.org&utm_medium=readme&utm_campaign=wp-fail2ban-premium-5.4.1" rel="nofollow ugc">Cloudflare</a>, and the Premium version will automatically update the list of Cloudflare IP addresses. 
You can also configure your own list of trusted proxies.
</li>
<li>
syslog Dashboard Widget 
Ever wondered what’s being logged? The dashboard widget shows the last 5 messages; the Premium version keeps a full history to help you analyse and prevent attacks.
</li>
<li>
Site Health Check 
WPf2b will (try to) check that your <code>fail2ban</code> configuration is sane and that the filters are up to date; out-of-date filters are the primary cause of WPf2b not working as well as it can. 
When did you last run the Site Health tool?
</li>
<li>
<code>mu-plugins</code> Support 
WPf2b can easily be configured as a “must-use plugin” – see <a href="https://docs.wp-fail2ban.com/en/5.4/configuration.html?utm_source=wordpress.org&utm_medium=readme&utm_campaign=wp-fail2ban-premium-5.4.1#mu-plugins-support" rel="nofollow ugc">Configuration</a>.
</li>
<li>
API to Extend WPf2b 
If your plugin can detect behaviour which should be blocked, why reinvent the wheel?
</li>
<li>
Event Hooks [Premium] 
Need to do something special when WPf2b detects a particular event? <a href="https://docs.wp-fail2ban.com/en/5.4/developers/events.html?utm_source=wordpress.org&utm_medium=readme&utm_campaign=wp-fail2ban-premium-5.4.1" rel="nofollow ugc">There’s a hook for that</a>.
</li>
</ul>
<h4>Premium</h4>
<ul>
<li>Web Application Firewall (WAF)</li>
<li>Akismet support.</li>
<li>Block XML‑RPC while allowing Jetpack and/or Pingbacks.</li>
<li>Block Countries.</li>
<li>Auto-update Cloudflare IPs.</li>
<li>Event log.</li>
<li>Event hooks.</li>
</ul>

WP fail2ban – Advanced Security

Recent spam and brute force attacks prompted me to install this plugin on my multisite network, and it works really well! It needs some minor configuration on the server up front, but once that was all set, it instantly started banning IP's that violated the defined filters. Highly recommended.

Minor point of criticism: links to the documentation don't work in the plugin

Must have for self-hosted WordPress sites

Ok, this is the kind of plugin I keep installing and deinstalling over time...

Firstly: I'm no stranger to fail2ban, but I'm not really an expert in designing my own filters, either. I still know enough fail2ban-fu to tackle some tricky issues; ultimately, 90% of the complexity is in setting the correct regexps to catch log errors — that's easy enough to do :-)

Secondly: as an experienced system administrator, the extra goodies that come with the subscription model are not really worth the expense. Some of those goodies are basically just automating procedures for those that aren't really familiar with fail2ban. Sure, the so-called Blocklist Network Service (BNS) is quite useful for preemptively block malicious IP addresses; but, as others have said elsewhere, you can pretty much accomplish the same with many other tools (most of them free). I mostly use AbuseIPDB (as well as the free version of WordFence), but your mileage may vary.

Thirdly: aye, the constant nagging to upgrade to Premium is annoying. After a while it gets on your nerves. Sure, programmers need to eat, too, so I perfectly understand the need to grab the user's attention. I personally would prefer a one-shot fee to get most of the Premium functionality, or at least a way to turn off the constant nagging, like others already suggested; committing to a permanent subscription plan, no matter how cheap, is not really an option for those, like myself, who have irregular sources of income, and have to keep recurring payments at the bare minimum (e.g. utility bills...). I'd be fine to have very limited 'Premium' features for a single payment, and, sure, I'd pay US$40 for the privilege of not getting constantly nagged about upgrading...

Fourthly: documentation. It's clear that Charles has put a huge effort in writing the documentation. Alas, the brunt of the effort was done around version 2 of wp-fail2ban. Recent features are barely documented, if at all (sometimes you only know that a feature exists, but have no idea about its purpose; sometimes there isn't even an empty page for said feature, so you have no way to know if it exists at all or not — short of taking a look at the source code, that is).

Put in other words: to do the basics, there is enough documentation. To go a little further than that, or to figure out how to activate a recently introduced feature... well, there is often not enough help for that on the documentation. If you really need that feature, I guess you'll have a good incentive to go Premium :)

That said, is this plugin really that useful? You bet it is!

There are a few other plugins attempting to do the same — i.e. integrating the WordPress logs with fail2ban — but they don't come even close. WP Fail2Ban goes way, way further than other plugins. A lot of features have been very cleverly implemented (for instance, even if a hacker gets access to your website's admin panel, despite all the protections, they'll have a tough time to fully disable the plugin...) and work quite well in practice. What is not even mentioned on the documentation is that, by default, if you host a lot of websites, and all of them have WP Fail2Ban active, then a single filter on fail2ban will deal with blocking them all. That's because WP Fail2Ban will add entries to syslog — which is common to the whole system. This is far better (and much faster!) than scanning each individual virtual host's logs! Also, you get correlations that aren't obvious, and can act upon those as well.

Imagine the following scenario: a malicious hacker figured out that your server's IP address is actually hosting hundreds of separate websites. They have a brute-force script to try to guess passwords, but they also know that most WordPress installations, even quite basic ones, will block failed attempts after a while. So, what they do is to run the script across all websites, one by one, giving plenty of time between attempts — thus expecting to evade the most basic defence. A website that sees three failed logins in 'quick' succession can block that IP address effectively. But websites are independent of each other, so they cannot know if the others are being simultaneously being attacked or not; eventually, the failed attempt is 'forgotten' over time, and even if a request comes from the same IP address after an hour or two, it's likely that the defence system might not associate one thing with the other. It's just repeated attempts for the same login (usually from the same IP!) that trigger most alarms...

Not so with WP Fail2Ban. Those hundreds of sites will all promptly log a failed attempt to the same universal log, syslog. Thus, fail2ban will immediately notice that there is someone attempting to log in — and failing all the time — on any of the websites, and, as a result, will count failed attempts on one site towards a common total. The result? Such a brute-force attack can easily be detected, promptly logged, and blocked — for all websites, not just for one!

Even if you run multiple servers, each with different physical IP addresses, that's not a problem. syslog can be configured to accept remote logging from multiple sources. You might need to do a bit of tinkering (i.e. deciding which logging facility will be kept on the local machine, and which will be stored remotely), but such a configuration is certainly possible (WP Fail2Ban can be configured to use any syslog logging level/facility!). Sure, this requires a bit of extra scripting, but it's not a really hard thing to do — especially if you are able to instruct fail2ban to block IP addresses at the level of a common (physical) firewall.

A very easy way to accomplish the same is to use something like Cloudflare: configure fail2ban to use Cloudflare's API to block an IP address at their firewall, and that address will be automatically blocked for all websites you've got protected with Cloudflare. All that for the modest cost of zero dollars.

Another interesting feature is the ability to extend WP Fail2Ban with additional plugins. A few can be activated directly from the WordPress Plugin Library (e.g. to protect your Contact 7 or Gravity forms). But you can also write your own plugins to deal with particular configuration. This mostly means telling WP Fail2Ban what to trigger and write to syslog, and adding a fail2ban filter to seek for that message and process it accordingly. That way, you can add lots of additional functionalities that are not present in the 'core' WP Fail2Ban plugin, but which might be quite useful.

Here is an example. fail2ban is mostly used to ban IP addresses, but it can do a lot more: an easy example is just to alert the system administrator that something is not working as it should, and send them an email (or a tweet, or something...). You can write a simple plugin to check for available memory (available to WordPress, that is), and if it's excessive (according to your own rules!), write a message to whatever syslog level you wish — and let fail2ban pick it up from there, eventually sending an alert. While this can be accomplished in several different ways, from the perspective of a system administrator, it's more manageable to have a 'common' framework for identifying malfunctions and/or (possible) security issues and configure them from the same interface (in this case, fail2ban scripts). By combining the ability of WP Fail2Ban to potentially register whatever is happening with your WP installation and write a message to syslog about it, and having fail2ban picking up those messages and extract a pattern that shows that something is wrong, you can effectively build a complex system around those tools that can give you a lot of insight on what's going on with your websites — and automate many of the tasks (fail2ban can attempt to restart a PHP instance that has been consistently reporting many out-of-memory errors, for example).

I'm aware that there is a plethora of such tools available (New Relic comes to mind — just because it has a free tier, and it's enterprise-grade instrumentation), but combining the power of WP Fail2Ban with fail2ban itself and using syslog as a way to pass messages between both — that's pure genius, and a very clean and elegant way of doing even complex, automated tasks, just by using off-the-shelf tools (most of them free!).

You can see that I have listed way more reasons why I love the concept behind WP Fail2Ban than the reasons why I hate it. I would say that it's the kind of plugin that you will actively use (it works in the background, after all), even though you can achieve similar results by adding lots of clever rules on fail2ban (without needing the extra help from WP Fail2Ban, that is). There are always trade-offs to consider — for example, where are you more comfortable dealing with security, at the WordPress level, or at the operating system level? (the correct answer, of course, is 'both' — but that might not be an option for everyone)

Also, I'd rate WP Fail2Ban as being a 'comparatively light' plugin. It does use a few database calls, just for presenting the last five reported incidents on the dashboard — but you can even turn those off and save the cost of those database accesses. After all, most of the work will be done by fail2ban anyway — running silently in the background. WP Fail2Ban is just a very sophisticated logging tool (and the 'core' WP engine already does its share of logging, so it's not too much extra work), mostly providing a reasonably easy interface inside WordPress to configure how those 'special' logs ought to be written to syslog; that will hardly put too much stress on your own system (and syslog is designed to handle that stress!).

A last note: I've repeatedly mentioned that WP Fail2Ban relies on syslog to write appropriate messages to it that fail2ban can capture and process, but there are different ways to configure it — you can bypass syslog, write the logs elsewhere (even on a memory-based filesystem, if you wish!), and just process these with fail2ban (which is rather agnostic about where it should look for logs). Using syslog (especially its built-in remote logging facilities!) might be a better solution in many scenarios, but it's not a requirement for you to use WP Fail2Ban.

I have a love-hate relationship with this plugin...

WP fail2ban uses fail2ban to protect your WordPress site.

Web-Art Login Shield with reCAPTCHA vs WP fail2ban – Advanced Security