Support

As per https://www.akeeba.com/documentation/admin-tools-joomla/waf-log.html#waf-log-reasons (scroll all the way to the bottom) this corresponds to the Block Suspicious Core Parameters feature which was added in version 7.4.5. You can read the documentation of this feature here: https://www.akeeba.com/documentation/admin-tools-joomla/web-application-firewall.html#wafconfopt-susparams (this page is linked to from the previous one).

There is currently no such option. It will be added in the next release.

In the meantime, you should take the opportunity to fix the underlying problems on your sites, or disable this feature if you're going to ignore it anyway.

Joomla! addresses vulnerabilities in the core code, not in third party code. It also addresses issues which are known, not issues which are not yet known. The idea of this feature, as well as all Web Application Firewall features, is to mitigate as much of the impact of the as-yet-unknown vulnerabilities as possible.

For example, when there was a major zero-day issue in Joomla! back in December 2015 that involved a SQL injection attack vector, sites running Admin Tools with its SQLiShield feature were not vulnerable. Admin Tools would catch the SQL injection and block it before it reached any part of the core code where it could do any damage.

The core parameters in question are reserved by Joomla, meaning they shouldn't be used for anything else by third party code. They always have a specific context they operate in, and filtering that needs to be applied to them. Even though they are processed by core code, they can be modified by third party code which may or may not be applying adequate filtering.

So, yes, this feature is useful in catching invalid uses of these core parameters be it an attack attempt, or a coding mistake in a third party extension. What I told you is that if you are sure it's not a legitimate attack, ask the developer of the third party extension to fix their problematic code.

In the meantime, if this feature working as it should but other third party code doing silly things it shouldn't be doing is causing an operational problem on your site you can of course disable this feature either globally through the Configure WAF page, or using a WAF Exception.

If, however, you do not have an operational issue on your site, you understand and agree that this feature like all features in a security extension has a purpose to serve, and your only problem is the emails you keep getting you have two options. One option is to just wait until the next version, when you will be able to exclude this reason from emails. The other option, and the one I recommend, is disabling all emails for blocked requests by removing your email address from the relevant Configure WAF field. These emails are meant to be a crutch during development and troubleshooting, not something you will keep enabled forever. A request is blocked, let Admin Tools handle that. You don't need to know about it. What's the point of automating security if you want to spend all your time micromanaging it?