Background Request Blocked

Hi @queermdb, thanks for your question.

Any administrator-triggered actions such as this, because they occur and alert you as soon as the action (in this case a post edit) is performed, will not be treated the same as an external or failed login request that you would see in Live Traffic.

As you are aware of what is trying to be done at the time and it is a normal action that you’ll frequently be using, it is safe to “Add action to allowlist”.

Thanks,

Peter.

How can I know what caused this block request? It sometimes occure without any action? I would deactivate plugins but we are using too many to find the source on this way?

Is there a loglist with every block issue?

Hi @queermdb, thanks for getting back to me.

False-positives can arise from time-to-time, and these requests to “Add action to allowlist” when you’re seemingly just loading a page can occur with background requests that plugins are using. For example, if a plugin needs to make a POST/GET request for information in the background and does so via a file such as admin-ajax.php, they can sometimes be flagged too but are usually safe to allow in order for the plugin to function correctly. Sometimes though trial and error with enabling/disabling plugins can be a useful process to identify causes of these blocks or determine whether you should disable any of your installed plugins.

You can also enable Learning Mode to teach Wordfence that the actions you’re seeing are normal.

From the Wordfence Dashboard click on Manage WAF. Then you will see Basic Firewall Options > Web Application Firewall Status. Change the option to Learning Mode. Now attempt again to edit posts, or load pages that were flagging up before. This will help Wordfence learn that these actions are normal and it will allow them in the future. After you have finished testing, switch the WAF from Learning Mode back to Enabled and Protecting. Now test to see if these actions/page loads work correctly.

If your scan ever specifically shows modified plugin files that don’t match the www.ads-software.com approved versions or flags potentially malicious code found then you may need to perform a site clean but that doesn’t seem to be what’s happening here.

Blocks can be seen on the Live Traffic page when filtered by “Blocked” or “Blocked by Firewall”. Also, you can look at any data in Wordfence > Firewall > Blocks, which again can be filtered to your preference.

Thanks,

Peter.

This was “blocked by firewall for XSS: Cross Site Scripting in POST body: matomo_code=%3C!–%20Matomo%20–%3E%0D%0A%3Cscript%20type%3D’text%2Fjavascript’%3E%0D%0A%20%20var%20_paq%20%3D%2…”

The problem: I don’t use Matamo. So I won’t whitelist it. Anyone knows what happens here?

Hi @queermdb, thanks for the information.

We have seen exploits to a historically vulnerable version of WP-Matomo plugin into displaying a remote script, but if you don’t have that plugin installed then it may be a blanket attempt to access your site and execute code on the off-chance you do. Many attackers will not check for plugins or WordPress version before attempting access as it’s too time consuming – so may just act in a “hit and hope” manner.

I certainly wouldn’t whitelist this action regardless of the status of Matomo on your site. You could quickly check that your theme doesn’t have Matomo analytics functionality built in for people with an account choosing to integrate it.

Let me know if you see anything else suspicious crop up.

Thanks,

Peter.