TL;DR

WP fail2ban Premium analyses the database query WordPress is about to run and checks whether input from the request has altered its structure. That lets it recognise the defining behaviour of SQL injection without a signature for the payload or prior knowledge of the vulnerable plugin.

The detector is currently experimental. Begin in logging-only mode: WP fail2ban records its decisions in the event history while allowing the queries to run. Once you are satisfied with the results, blocking mode can stop the query and write the attempt to the dedicated WAF filter for fail2ban.

Inspect the query the application actually built

The same input can be harmless in one context and dangerous in another. A word that resembles SQL is still only data if the application keeps it inside the value where it belongs.

WP fail2ban waits until WordPress or a plugin has built the query. It can then see whether input from a query string, form, cookie, or REST request remains data or has become part of the SQL instruction.

The decision is based on what the application is about to send to the database.

Detect the change that makes it an injection

An injected value changes the grammatical structure of the query. WP fail2ban parses the SQL and checks whether request input crosses from one part of that structure into another.

That gives the WAF a stable property to detect. Attackers can change spelling, spacing, encoding, and the rest of the payload, but a successful injection still has to change what the query tells the database to do.

The WAF therefore does not need an ever-growing catalogue of malicious strings to recognise the attack.

Protect vulnerable code before a signature exists

A vulnerability can be exploitable before the plugin author, site administrator, or security vendor knows it exists. A payload signature can only protect against an attack someone has already recognised.

WP fail2ban does not need to identify the vulnerable plugin. If user-controlled input breaks into the structure of the resulting query, the WAF can identify the operation by its behaviour.

That does not make patching optional. It gives you protection at a different boundary while an unknown or unpatched vulnerability is present.

Put the protection where it earns its cost

Most WordPress SQL injection vulnerabilities occur in plugins, so WP fail2ban lets you protect plugin queries without automatically applying the same work to every query WordPress core makes.

Core-query inspection is also available, but it is not recommended for normal use. SQL injection vulnerabilities in WordPress core are extremely rare, and the additional analysis applies to many more queries with a greater performance cost.

Current coverage includes query-string, form, cookie, and REST input. Raw HTTP headers are outside the SQL injection check.

Move from observation to blocking

Logging-only mode records detections in the event history while allowing the queries to continue. It does not send those preview decisions to the dedicated WAF filter because it has not blocked them.

Once you have checked the results against the normal behaviour of your site, blocking mode can stop the query before it reaches the database. It then writes the attempt to the dedicated WAF filter, so a configured fail2ban jail can stop the source at the host firewall.

SQL injection detection remains experimental while it is tested against a wider range of real WordPress queries and plugin behaviour.

More about the WordPress-aware WAF.