Recurring WAF (ModSecurity) issue with Brizy updates on cPanel

Kazimierz Karczewski

• March 31, 2026 10:21

Hi KC George,

I wanted to share a quick note from our side after resolving a recent issue with Brizy on a cPanel/CloudLinux server using Imunify360 WAF.

We encountered repeated 413 (Request Entity Too Large) errors and request blocking during page updates in Brizy. After investigation, the root cause was not PHP limits but ModSecurity (WAF) request body limits and inspection rules interacting with large Brizy payloads.

Increasing the following ModSecurity limits resolved the issue:

• SecRequestBodyLimit
• SecRequestBodyNoFilesLimit
• SecRequestBodyInMemoryLimit

However, based on this behavior, it looks like future Brizy updates (especially those increasing payload size or changing request structure) may trigger the same WAF-related issues again on standard cPanel + Imunify360 setups.

It might be worth considering:

• documenting recommended WAF/ModSecurity limits for Brizy
• or implementing safeguards/workarounds for environments with strict request inspection

This seems to be a recurring pattern on hosting stacks with aggressive WAF configurations.

Just sharing this as feedback from production — everything is working now after tuning, but the issue will likely reappear for others.

Best regards,
Kazik Karczewski

0

• 

  KC George

  • March 31, 2026 10:35

  Hello Kazik,

  We usually recommended the following ModSecurity limits in case of 413 errors.

  SecRequestBodyLimit 4194304
  SecRequestBodyNoFilesLimit 2097152

    SecRequestBodyInMemoryLimit needs to be set based on the available RAM on the server.

  0
• 

  Kazimierz Karczewski

  • March 31, 2026 12:03

  Thanks for your reply.

  I tested the recommended ModSecurity limits:

  • SecRequestBodyLimit 4194304
  • SecRequestBodyNoFilesLimit 2097152

  Unfortunately, in a real production scenario with Brizy, these values are simply too low. The editor generates significantly larger POST payloads (JSON + base64 content), and with those limits in place the request body parsing fails, resulting in 413 errors or WAF interference.

  In our case, the issue was resolved only after increasing the limits substantially (e.g. 100MB+). This suggests that current recommendations may not reflect actual payload sizes produced by Brizy, especially on more complex pages.

  From an operational perspective, this creates a recurring problem on typical hosting stacks (cPanel + CloudLinux + Imunify360), where default or recommended WAF limits are too restrictive for modern page builders.

  It might be worth revisiting these recommendations or documenting more realistic values for environments using Brizy in production.

  Everything is working correctly now after adjusting the limits, but I expect this issue will continue to affect other users unless addressed.

  Best regards,
  Kazik

  0

Please sign in to leave a comment.