WordPress upload false positives with Cloudflare OWASP Core Ruleset

Hi all,

Has anyone else experienced false-positives using WordPress with the Cloudflare OWASP Core Ruleset. Performing any WordPress upload of an image triggers all manner of the OWASP rules and puts the anomaly threshold very high. I’ve been completely unable to use this ruleset not mitigate the issue through firewall rules.

This is my first account with the new WAF rolled out. I’ve never had these kind of issues with the older WAF running on my older accounts.

I get a: “949110: Inbound Anomaly Score Exceeded” error with an anomaly score of 87, triggering many different legit rules (19) in total:

920270: Invalid character in request (null character)
920271: Invalid character in request (non printable characters)
920272: Invalid character in request (outside of printable chars below ascii 127)
942440: SQL Comment Sequence Detected

including odd matches such as: 933100: PHP Injection Attack: PHP Open Tag Found
even though the uploaded file is a PNG (any png) and there’s no meta data within the file which looks like a PHP open tag.

in addition to this, any firewall rules I create to mitigate this issue by targeting the upload URL seem to run after the managed firewall rule when it’s too late and the request is already blocked or challenged.

Thanks in advance for any insight you may have!

The same is happening to me (first time CF user) on a Magento 2 installation.
The file uploader, called via AJAX, is working for me personally but it’s not for my client. The only obvious difference between the two of us is that she’s using a Mac.
As the original poster, we get all kinds of rules triggered (up to 25). The firewall is even blocking the saving of products for her - the URL is something like /admin/catalog/product/save/id/15247/type/configurable/store/0/set/15/key/6d2dfc1fe5c08345850d6dbcc8e71b3d4a39b066b81cf97ec18770abdc8069f5/ and is called via POST.
Lowering the paranoia level down to 3 (from 4) did not help either.

Hi @dev151,
I figured it out. All the previous techniques (still recommended on the CF docs) like firewall rules, lowering security or paranoia levels and even page rules no longer work with the new CF Firewall.

To fully disable the firewall on the Wordpress admin area, do the following:

  1. Go to Firewall > Managed Rules > Configure under “Cloudflare OWASP Core Ruleset”
  2. Go to “Edit Filter” under Cloudflare OWASP Core Ruleset
  3. Choose “Custom filter expression” and enter the following settings:
    *Field = URI Path
    *Operator = does not contain
    *Value = /wp-admin/

The above finally worked for me.

1 Like

Allow Server (Origin host) IP in firewall->Tools will resolve this issue.

Thanks for the responses. @user3011 your reply does not work. The AJAX requests made to /wp-admin/async-upload.php are made via the visitor IP address.

@luca5 I feel your solution is more of a workaround. Just because the wp-admin section of the website is protected by authentication it does not mean it should have no firewall rules. Consider a member site or plugins that use /wp-admin/admin-ajax.php for AJAX requests.

I did follow in your footsteps and added a filter but specifically for /wp-admin/async-upload.php rather than the entirety of the admin system. Thanks for the suggestion. It’s a good step forward but there must be a better solution out there.

Thanks again,

There’s a new firewall which doesn’t follow the documented behavior?

@robb that’s correct. Details below. It has been rolled out to recently created accounts:

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.