WordPress-aware WAF » Protect sensitive WordPress options
TL;DR
WP fail2ban Premium checks permission when a sensitive WordPress option is changed. In blocking mode, it stops an anonymous or otherwise unauthorised update at the operation itself, regardless of which plugin, route, or vulnerability exposed it, then writes the attempt to the dedicated WAF filter for fail2ban.
The recommended mode protects the full set of consequential core options, while a theme-compatible mode permits specific image-size updates during theme setup. Start in logging-only mode: WP fail2ban records its decisions in the event history while allowing the updates to continue, so you can see what blocking would affect before you enforce it.
Protect the settings that can change the site
The protected set comes from WordPress. It includes, for example, the site address, home URL, administrative email, whether registration is open, and the default role assigned to new users. Changing one of these values can redirect the site, move administrative communication, open account creation, or give new accounts the wrong privileges.
An attacker only needs vulnerable code to expose the change without requiring an authorised administrator. WP fail2ban protects the consequential core settings without treating every option as equally dangerous.
Stop anonymous changes at the update itself
WP fail2ban checks permission at the point where WordPress is about to update the option. In blocking mode, an anonymous request cannot make the protected change: the WAF stops it and writes the attempt to the dedicated WAF filter for fail2ban. The protection follows the operation, regardless of which plugin, route, or vulnerability exposed it.
The same check also stops a logged-in user who lacks the required permission.
Keep legitimate theme setup working
The recommended All mode protects the full set. Some themes legitimately update WordPress's thumbnail, medium, and large image settings while they initialise, so WP fail2ban also provides a Theme mode for that case.
The Theme exception is limited to those image-size updates during theme setup. You can preserve the expected setup behaviour without abandoning the rest of the protection.
The check has no meaningful performance cost; the remaining question is whether existing code assumes the update will always be accepted.
See what enforcement would change
Logging-only mode records the option updates WP fail2ban would stop while allowing them to continue. Because it has not blocked the operation, it does not send the preview decision to the dedicated WAF filter.
Some themes and plugins assume an option update will succeed because WordPress does not normally enforce permission at this point. Even legitimate code can depend on that assumption.
You can use the log to decide whether the affected behaviour needs the theme-compatible mode, a different configuration, or a correction in the code that requested the update.
The permission check itself is not experimental. Logging first is how you introduce a low-level control without discovering a compatibility problem on the live site.
