WordPress-aware WAF
TL;DR
The WP fail2ban WAF checks important operations where WordPress understands what a request will do. It can analyse a database query after WordPress has built it and check permission when an anonymous request tries to change sensitive options or delete a user account.
That application context lets the WAF detect the defining behaviour of an attack instead of depending entirely on signatures written for attacks already known. In blocking mode, it stops the prohibited operation inside WordPress and writes the attempt to the dedicated WAF filter for fail2ban.
All three controls are included in WP fail2ban Premium. Start in logging-only mode: WP fail2ban records its decisions in the event history while allowing the operations to continue. This is a compatibility precaution for option changes and user deletion; SQL injection detection is additionally experimental while its analysis is tested across a wider range of real queries.
Make the decision where the meaning is clear
WP fail2ban watches those operations at the point where WordPress is about to carry them out. It can judge the result of the request rather than trying to infer its purpose from the URL or payload alone.
An incoming request does not reveal everything that will happen inside WordPress. A harmless-looking value may eventually alter the structure of a database query. A plugin vulnerability may let someone who is not logged in reach an operation that should only be available to an administrator.
That WordPress context is what makes the three controls a coherent WAF policy.
Detect SQL injection without an attack signature
WP fail2ban analyses the query WordPress is about to run and checks whether input from the request has crossed that boundary. It does not need a signature for the particular payload or prior knowledge of the vulnerable plugin.
SQL injection happens when input supplied as data changes the structure of a database query. The query itself reveals whether that boundary has been crossed.
You can protect queries built by plugins, where most WordPress SQL injection vulnerabilities occur, and separately decide whether to inspect WordPress core queries as well.
More about blocking SQL injection without attack signatures.
Stop anonymous requests from making privileged changes
WP fail2ban checks permission when a protected option is about to change or a user account is about to be deleted. It can stop the anonymous user at the operation itself, regardless of which plugin, route, or vulnerability led there.
Some plugin vulnerabilities expose a legitimate WordPress operation without checking that the person making the request is allowed to use it. The WAF closes that missing permission boundary and records the attempt.
Choose the controls that fit the site
The three protections do not have to be treated as one switch. You can apply the SQL injection checks where they provide the most value, choose the appropriate option-protection mode for your theme, and protect user deletion independently.
That matters in WordPress, where two sites may share the same core software but have entirely different themes, plugins, users, and administrative workflows. WP fail2ban gives you controls at the important boundaries without pretending that every installation behaves identically.
See what blocking would change
Logging-only mode records each operation the WAF would stop while allowing it to continue. You can see how the policy fits your existing site before you enforce it.
The WAF operates at low-level WordPress boundaries. This lets one check protect an operation across different routes and plugins, but existing code may assume the check does not exist. An option update that WordPress would normally accept is one example.
You can review the logged results, identify any legitimate code that would be affected, and move to blocking once you know the policy works with your site.
Start with logging only for all three controls. With option changes and user deletion, this is a compatibility precaution around straightforward permission checks. SQL injection detection also needs validation against a broader range of real WordPress queries, so it remains experimental for now.
Stop the operation, then stop the source
The WAF's first layer acts inside WordPress at the moment it has enough context to make the decision. It stops the prohibited database query, option change, or account deletion. This protection does not depend on access to fail2ban, so it still works on a managed host where you cannot configure a jail.
In blocking mode, WP fail2ban also writes the attempt to the dedicated WAF filter, separate from the extra, soft, and hard filters used elsewhere. Where you can configure fail2ban, a jail can prevent further requests from the same source reaching WordPress at all.
WP fail2ban Premium gives you immediate protection inside WordPress wherever it runs, plus efficient enforcement at the host firewall where that is available.
