WooCommerce 8.5.1 issues with Web Application Firewall (ModSecurity)

Since the release of WooCommerce 8.5.1 yesterday, we received reports about stores getting 403 Forbidden errors caused by Web Application Firewall (WAF) rules set up in their hosting configuration while the Order Attribution feature is enabled. We have identified a number of server configurations affected by this issue, and would like to suggest several workarounds while we work on a solution.

How can I tell if this affects me?

If you have the Order Attribution feature set to enabled and, you also have Web Application Firewall (WAF) rules set up in your hosting configuration, you may be affected.

📝 Important: The Order Attribution feature is set to enabled by default as of 8.5.0. Check the Order Attribution feature docs to disable this if you are affected.

What action should I take?

Plesk already has a help article targeting this issue, identifying Comodo rule with ID 218500 being false-positively triggered when Woocommerce 8.5 is in use. They recommend disabling the rule following the steps on their page.
Check with your host to see if ModSecurity is enabled. If that is the case, you may ask your host to adjust the firewall rules to allow the cookies set by Woo’s Order Attribution feature. You can find more information about the cookies used by this feature in our documentation.
If the above doesn’t work for you, disable the Order Attribution feature to prevent future users from seeing the 403 errors by going to WooCommerce > Settings > Advanced > Features and toggling the Order Attribution feature off.

We are currently working with the affected hosting solutions to address the root cause of the issue. We will certainly make an announcement in this blog when it is resolved.

Special thanks to these contributors for raising this issue:

MarkTallentire for reporting #43413
herlbauer for reporting #43681

Keep yourself in the loop!

34 responses to “WooCommerce 8.5.1 issues with Web Application Firewall (ModSecurity) ”

daiv11

January 16, 2024

I have 5 sites using Woocommerce. When I disabled the above rule ID, it worked great on 4 of them. On one site, I got a 500 internal server error and it only works if I completely turn off the firewall.

Reply
1. Julia Amosova
  
  January 25, 2024
  
  Thank you for confirming that the issue had been resolved on 4 of your sites after adjusting the firewall settings. When it comes to remaining site that gives you troubles – can you please provide us with the name of your hosting company which can help us in resolving this further.
  
  Reply
TheWebSmiths

January 22, 2024

A new ModSecurity rule set for Comodo (free) has rolled out within Plesk this morning which seems to have resolved the issue across all my affected sites.

Reply
1. Julia Amosova
  
  January 25, 2024
  
  This is great to know! Thank you for confirming.
  
  Reply
Astrid

January 25, 2024

Hi, on my website the Order Attribution feature is enabled. But I had stil problems. Now the hosting adjust the firewall rules. Now the website looks oke. Can I wait for a new relaese from Woocommerce? Or must I take other actions?

Reply
1. Julia Amosova
  
  January 25, 2024
  
  Thank you for letting us know that the issue had been resolved on your site after the hosting company adjusted the firewall settings. It is great news!
  
  As far as the next steps, we released WooCommerce 8.5.2 today, however, it doesn’t resolve the firewall issue yet. We are still working on the solution to address the root cause of the issue. We will announce on this blog once it is resolved – please keep an eye on it. There is nothing to do in th meantime though – you seem to be all set.
  
  Reply
  1. Astrid
    
    February 21, 2024
    
    Hi Julia,
    
    Is the problem solved? So that I can update Woocommerce on my website?
    
    Reply
    1. Justin (Woo)
      
      February 29, 2024
      
      Hi Astrid,
      
      The false positive has been recognized by some of the most common web application firewall ruleset providers: Comodo released a patched ruleset, but OWASP currently recommends adding an exclusion rule. You can find more information in the Order Attribution Tracking documentation here: https://woocommerce.com/document/order-attribution-tracking/#h-cookies-are-blocked-by-a-web-application-firewall-waf
      
      We’re also looking at changes that we can make to avoid the false positives, but will need more time to implement (and thoroughly test) them before including them in a WooCommerce release.
      
      In the meantime, if you are continue experiencing WAF issues after updating to the latest version of WooCommerce – Order Attribution will be enabled by default – you can disable the feature in Settings, or programmatically with PHP or the WP CLI. You can find examples for doing so in the Order Attribution Tracking documentation linked above.
      
      Reply
Ingeborg Kriegsman

January 28, 2024

Again It is not possible for me to enter my website and webshop. Did the release of 8.5.2. change anything with the firewall again?
After the release of 8.5.1. my hosting company changend something so I had access again.

Reply
1. Justin (Woo)
  
  February 29, 2024
  
  Hi Ingeborg, there were no specific changes between 8.5.1 and 8.5.2 that should have caused new issues.
  
  The false WAF positive has been recognized by some of the most common web application firewall ruleset providers: Comodo released a patched ruleset, but OWASP currently recommends adding an exclusion rule. You can find more information in the Order Attribution Tracking documentation here: https://woocommerce.com/document/order-attribution-tracking/#h-cookies-are-blocked-by-a-web-application-firewall-waf
  
  You may need to reach out to your hosting company again (if you haven’t already).
  
  Reply
Giovanni Frino

January 29, 2024

I’m also waiting for the fix, we are an agency and all our client websites were down due to the WooCommerce update now we roll back to WooCommerce 8.3.1 and waiting for a version that fixes the issue.

Reply
Rano

January 30, 2024

Thanks that you are still working on the solution to address the root cause of the issue.

Reply
Giovanni Frino

February 21, 2024

This problem come up a month ago, ever since I run v8.3.1 on about 200 websites we manage, how is possible WooCommerce didn’t fix this problem yet?

Reply
1. Justin (Woo)
  
  February 29, 2024
  
  Hi Giovanni, thanks for your feedback and for following up. Please see my reply above to Astrid regarding the status of the feature with a link to the documentation that contains current known solutions and workarounds: https://developer.woocommerce.com/2024/01/16/woocommerce-8-5-1-issues-with-web-application-firewalls-modsecurity/#comment-12057
  
  Reply
Gayashan Jayasinghe

February 28, 2024

the issue is still the same with WooCommerce Version 8.6.1
When can this be fixed?
I rolled back to WooCommerce 8.3.1, and still the same.
The site is hosted in Xserver.

Reply
1. Justin (Woo)
  
  February 29, 2024
  
  Hi Gayashan, thanks for your feedback and for following up. Do you know what WAF ruleset Xserver uses?
  
  Please refer to my reply to Astrid above regarding the status of the feature with a link to the documentation that contains current known solutions and workarounds: https://developer.woocommerce.com/2024/01/16/woocommerce-8-5-1-issues-with-web-application-firewalls-modsecurity/#comment-12057
  
  Reply
  1. Gayashan Jayasinghe
    
    March 1, 2024
    
    Hi Justin,
    Thanks for the reply. I fix the issue from the XServer end by changing the WAF settings.
    I turned off the Command countermeasures that detect accesses, including strings related to commands such as kill, FTP, mail, ping, ls, etc.
    
    Reply
Dagaloni

March 13, 2024

“Comodo WAF ruleset – released an updated ruleset to whitelist the cookies. If your WAF uses this ruleset, any issue should be resolved by updating to the latest version.”

What exactly is the latest version?

Reply
1. Justin
  
  May 13, 2024
  
  The latest version of the Comodo Web Application Firewall ruleset for Apache (which includes the fix for this false positive) is 1.241 (released 21 January 2024).
  
  Reply
  1. Dagaloni
    
    May 13, 2024
    
    Ok, thanks! I looks like the ruleset of directadmin is stuck on 1.233. https://files.directadmin.com/services/custombuild/cwaf/
    
    Reply
YK

March 29, 2024

When will an update be released that fixes this issue?

Reply
1. Justin
  
  May 13, 2024
  
  Hi @YK, we’ve been working on getting the cookies whitelisted in some of the main WAF rulesets, and we’re also working on changes (targeting WooCommerce 9.0) that should help solve a wider range of the issues associated to false positives in WAFs.
  
  Reply
  1. YK
    
    May 13, 2024
    
    @Justin
    
    Thank you for your reply.
    Waiting for new version.
    
    Reply
    1. Justin
      
      May 28, 2024
      
      Hi YK,
      
      WooCommerce 9.0 will include the new wc_order_attribution_use_base64_cookies filter, which enables Base64 encoding for order attribution cookie data, thus avoiding the specific substrings that have caused false positives in some WAFs.
      
      It can be enabled by adding this snippet:
      add_filter( ‘wc_order_attribution_use_base64_cookies’, ‘__return_true’ );
      
      Please let us know if that helps solve your problem!
      
      Reply
      1. YK
        
        May 28, 2024
        
        @Justin
        Where should I put this snippet in the new version?
      2. Justin
        
        May 28, 2024
        
        Hi @YK,
        
        You’d usually add the snippet to your child theme’s functions.php file. There’s a nice explanation in this video: https://www.youtube.com/watch?v=xQRLVBeAVt8
        
        Alternatively, you could create a custom plugin and add the snippet there.
Omar Paz

May 10, 2024

We got another merchant with Xserver here: https://wordpress.org/support/topic/woocommerce-8-5-1-issues-with-web-application-firewall/#post-17729873.

I’m asking for more details about the ruleset from their hosting.

Reply
1. Justin
  
  May 13, 2024
  
  Knowing which ruleset they are using will help us quite a bit for now. We’re also working on changes (targeting WooCommerce 9.0) that should help solve more of these WAF issues.
  
  Reply
pw7

May 20, 2024

Howdy. I enabled ModSecurity for our server and installed OWASP ModSecurity 2.9 Core Rule Set v3.3.4.

On the checkout page in WC 8.6.1, this caused the “Your order” and payment area to become greyed out and inaccessible. The order could not be completed.

Here are the logs: https://prnt.sc/kCa85KTRb3BX

Is there a workaround for me besides disabling Order Attribution? Thanks.

Reply
1. Justin
  
  May 20, 2024
  
  Hello, very sorry to hear about the ModSecurity issues. Have you confirmed that disabling Order Attribution re-enables the checkout page functionality? Some possible quick solutions include:
  
  Progressively adjusting Anomaly Score Thresholds or Security Levels: https://coreruleset.org/docs/concepts/anomaly_scoring/#configuring-anomaly-scoring-mode
  Adding exclusion rules for the offending rules to see if maybe a small number of exclusions gets your checkout working again: https://coreruleset.org/docs/concepts/false_positives_tuning/#rule-exclusions
  
  We’ll also be releasing a few more options in the coming releases of WooCommerce that may help sidestep these false positives.
  
  Please let us know how you get on and we’ll be happy to assist further if possible!
  
  Reply
  1. pw7
    
    May 20, 2024
    
    Thanks for the reply. No, disabling Order Attribution did not fix the problem.
    
    Reply
    1. Justin
      
      May 21, 2024
      
      Hi again pw7, thanks for confirming. If disabling Order Attribution doesn’t help, then your issue is probably unrelated to the one discussed in this post.
      
      I’m not a WAF expert, but it appears your issue is likely due to having the Anomaly Score Threshold or Security Levels set too high. The links in my previous comment explain further, or you may be able to find some answers from support (https://woocommerce.com/contact-us/).
      
      Reply
Stas

September 4, 2024

It still not working!

Cookies should not be created on first place this will solve the problem. There is EU-law about Cookies.

Cookies list:
– sbjs_current_add
– sbjs_current
– sbjs_first_add
– sbjs_first
– sbjs_migrations
– sbjs_session (not compatibile with EU-law, cookie should be set as session as all other)
– sbjs_udata

If we disable sec rule it works.
If we enable sec rule and visit direct wp-admin without cookies from home page it works.
If we enable sec rule and visit home and then wp-admin it doesn’t work.

Problem is related with latest version 9.x

This should be already fixed! But it is not.

Problem could not related with name of cookies but content of each cookies which has special characters like %20 (space) or similar symbols.

Why WooCommerce have 7 cookies?! Tracking user in EU is not great idea! There are EU-laws.

I hope you will solve this issue.

Reply
1. Justin
  
  September 9, 2024
  
  Hi Stas!
  
  Thanks for your feedback, have you tried the wc_order_attribution_use_base64_cookies filter solution mentioned in the documentation (https://woocommerce.com/document/order-attribution-tracking/#section-13)? This may help reduce the occurrences of special characters in the cookie content.
  
  EU cookie laws require consent for non-essential cookies, but allow essential ones for site functionality without consent. The feature does integrate with the WP Consent API in order to allow easier consent management (https://woocommerce.com/document/order-attribution-tracking/#section-15)
  
  Cheers!
  
  Reply