Brizy Builder generates oversized admin-ajax.php requests blocked by ModSecurity

Kazimierz Karczewski

• July 14, 2026 10:16

Hello Brizy Support,
Hello KC George,

We are experiencing a recurring compatibility problem between Brizy Builder and ModSecurity on multiple hosting platforms, including both cPanel and DirectAdmin.

When editing a page using the Brizy front-end editor, Brizy sends a large POST request to:

/wp-admin/admin-ajax.php

The request is rejected by ModSecurity with the following error:

ModSecurity: Request body no files data length is larger than the configured limit (131072)

Example:

[security2:error] ModSecurity: Request body no files data length is larger than the configured limit (131072). [hostname "domain.com"] [uri "/wp-admin/admin-ajax.php"], referer: https://pttk.pl/wp-admin/post.php?action=in-front-editor&post=18115

This is not an isolated hosting configuration issue. We have now encountered the same behaviour on:

• cPanel with ModSecurity,
• DirectAdmin with ModSecurity,
• different server configurations and web server stacks.

The default SecRequestBodyNoFilesLimit value is commonly set to 131072 bytes. Brizy exceeds this limit while saving or operating the front-end editor.

At present, the only available workaround is to increase:

SecRequestBodyNoFilesLimit

either globally or specifically for the affected domain. This is not an acceptable long-term solution, because it weakens an intentional request-size protection and requires hosting administrators to introduce product-specific ModSecurity exceptions.

Please investigate why Brizy generates such large non-file POST requests to admin-ajax.php.

In particular, please consider:

• reducing the amount of data transmitted in a single request,
• splitting large editor payloads into smaller requests,
• sending only changed page elements instead of the complete page state,
• compressing or optimising the editor payload,
• reviewing unnecessary or duplicated data in the request,
• providing official ModSecurity compatibility guidance.

Please also confirm:

1. What is the expected maximum request-body size generated by Brizy?
2. Is the entire page structure transmitted during every save or editor operation?
3. Is there an official recommended SecRequestBodyNoFilesLimit value?
4. Is this behaviour already tracked as a known Brizy issue?
5. Are you planning to modify the request mechanism in a future release?

The problem affects legitimate website administration and causes Brizy editing operations to fail on correctly secured hosting servers.

We would appreciate a technical response rather than a recommendation to disable ModSecurity. ModSecurity is an important security layer, particularly for WordPress installations and the heavily attacked /wp-admin/admin-ajax.php endpoint.

Please escalate this case to the Brizy development team.

Best regards,
Kazik Karczewski

0

• 

  Ariel H.

  • July 14, 2026 12:00
  • Edited

  Hi Kazimierz,

  Thank you for your detailed feedback and for bringing the issue to our attention.

  Could you please provide temporary administrator access to the WordPress dashboard? Alternatively, you may create a staging site where the issue can be reproduced.

  Please send the following details to communitysupport@brizy.io:

  Community Post: https://support.brizy.io/hc/en-us/community/posts/37221475512978
  WordPress Admin URL:
  Username:
  Password:

  - About the expected maximum request size, Brizy does not currently have a fixed maximum request size as more complex pages may exceed the 128 KB ModSecurity limit.

  - We also do not have an official recommended value for SecRequestBodyNoFilesLimit, since the required size varies by page. Based on our review, Brizy appears to update only the changed elements, although our developers can confirm this further.

  - We have previously seen similar issues with certain hosting providers, particularly GoDaddy hosted sites.

  Once we have access to a reproducible environment, we can inspect the site and forward it to the development team. Currently, we cannot confirm whether or when the request mechanism may be changed.

  Looking forward to your update.

  Kind regards,
  Ariel H.

  0
• 

  Kazimierz Karczewski

  • July 14, 2026 17:10

  Hi Ariel,

  Thank you for your response.

  I will send the WordPress access details in this email. KC George already has administrator access to the website, so the existing account may also be used to reproduce and investigate the issue.

  I am also the administrator of the DirectAdmin server hosting this website. If your developers require any additional server-side information, log excerpts, configuration checks, or temporary changes for diagnostic purposes, I can handle them directly.

  The issue can currently be reproduced while using the Brizy front-end editor, when the request sent to /wp-admin/admin-ajax.php exceeds the configured SecRequestBodyNoFilesLimit.

  Please note that tomorrow I will be working off-site at a customer location. I will have access to email, but my response time may be limited. If I am available and have a moment, I will perform any requested checks or configuration changes. Otherwise, I will address them as soon as possible afterward.

  Please let me know exactly what information, logs, or server-side tests your development team requires.

  Kind regards,
  Kazik Karczewski

  0
• 

  Ariel H.

  • July 14, 2026 22:17

  Hi Kazimierz,

  Thank you again for your patience.

   We recreated the issue on a test server using the same 128 KB ModSecurity request limit.

  Our testing confirmed your findings. When Brizy saves a complex page, it can send more than 128 KB of page data to WordPress. ModSecurity blocks the request before it reaches WordPress, resulting in the 413 error.

  After allowing the larger request, we also encountered 403 errors. These occurred because some OWASP ModSecurity rules interpreted legitimate HTML and CSS generated by Brizy as possible security attacks.

  We were able to restore editing by applying a limited server-side exception:

  - The larger request allowance was applied only to the affected website’s /wp-admin/admin-ajax.php endpoint.
  - ModSecurity remained enabled.
  - Only the rules confirmed as false positives were excluded for that endpoint.
  - Other websites and server endpoints retained their existing protection.

  For our test environment, a 4 MB limit was sufficient. The confirmed false-positive OWASP CRS rule IDs were:

  921130, 932105, 941100, 941140, 941160, 941270, 941310

  Your hosting administrator can use these findings as a starting point. We recommend that they review the ModSecurity audit log and apply the changes only to the affected domain and AJAX endpoint. The exact implementation will depend on whether the server uses cPanel, DirectAdmin, Apache, or Nginx.

  This does not require disabling ModSecurity globally. However, we recognise that it remains a server-side compatibility workaround rather than a change to Brizy’s request mechanism. I have documented the results for further review.

  Kind regards,
  Ariel H.

  0
• 

  Kazimierz Karczewski

  • July 15, 2026 17:35

  Hi Ariel,

  Thank you for the detailed investigation and for confirming the issue in your test environment.

  I am currently working on implementing a limited exception on the DirectAdmin server, restricted to the affected domain and the /wp-admin/admin-ajax.php endpoint. I will review the ModSecurity audit logs, apply only the required rule exclusions, and return with the results once I have completed the testing.

  I believe this issue deserves further attention from the Brizy development team. The current workaround is manageable for someone who has administrative access to the hosting server, understands ModSecurity and can safely analyse OWASP CRS false positives.

  However, this may become a serious operational problem when it is reported by a website administrator who does not also administer the hosting platform. In that situation, the user may only see unexplained 403 or 413 errors, while the hosting provider may be reluctant to modify security controls for a third-party page builder.

  It would therefore be valuable to consider reducing or restructuring the request payloads generated by Brizy and limiting the amount of HTML, CSS and page data transmitted in a single request. Clear official documentation for hosting administrators would also be helpful.

  I would also like to ask whether you can provide a more appropriate technical communication channel for matters of this type, rather than discussing detailed server configuration and security findings only through a publicly accessible community forum.

  Issues involving ModSecurity rules, WAF behaviour, server logs, request payloads and security exceptions should ideally be discussed directly between your developers and the responsible system administrator. Publishing detailed security-related configuration information publicly is not always appropriate.

  Given the current cybersecurity situation in our region, including sustained hostile activity associated with Russia, both Poland and Romania have good reasons to treat such matters carefully.

  Please let me know whether there is a private technical support channel, developer contact or secure ticketing process that can be used for further investigation.

  I will return with the DirectAdmin test results as soon as I have verified the configuration.

  Kind regards,
  Kazik Karczewski

  0
• 

  Ariel H.

  • July 15, 2026 23:25

  Hi Kazimierz,

  Thank you for taking the time to share your feedback.

  We understand your concerns about discussing server configuration and security-related information in a public forum. We also agree that reducing or restructuring Brizy’s request payloads could help prevent these issues and reduce the need for manual server-side workarounds.

  We do have a secure ticketing process. You can email your concerns and any sensitive technical details directly to support@brizy.io, and a private support ticket will be created automatically.

  We have already raised this issue with our development team for further review. However, please note that it may take some time to implement any necessary changes.

  Kind regards,
  Ariel H.

  0
• 

  Kazimierz Karczewski

  • July 16, 2026 07:53

  Hi Ariel,

  Thank you for the update. I appreciate that the issue has already been forwarded to your development team.

  I would like to share one additional suggestion from the perspective of a system administrator.

  Instead of relying on increasingly larger request-body limits and ModSecurity exceptions, it may be worth considering a different approach to the editor’s save mechanism.

  If technically feasible, Brizy could transmit only the modified elements (or smaller batches of changes) rather than large request payloads. An incremental or chunked update model could provide several benefits:

  * improved compatibility with ModSecurity and other Web Application Firewalls,
  * fewer false positives from OWASP CRS,
  * lower bandwidth consumption,
  * reduced Apache and PHP processing overhead,
  * better compatibility with reverse proxies and CDN/WAF services,
  * improved resilience on slower or less reliable network connections, where interrupted uploads would not require resending the entire page state,
  * improved scalability for large and complex pages.

  From a hosting provider’s perspective, this would significantly reduce the need for per-domain security exceptions while allowing secure default ModSecurity settings to remain in place.

  I fully understand that such a change would require architectural work and cannot be implemented quickly. I simply wanted to share the operational perspective from someone who manages production hosting infrastructure on a daily basis.

  Thank you again for taking this issue seriously and forwarding it to your development team.

  Kind regards,

  Kazik Karczewski

  0
• 

  Ariel H.

  • July 16, 2026 08:47

  Hi Kazik,

  Thank you for sharing your detailed perspective as a system administrator. We have added your full feedback, including the suggestion for incremental or chunked saving, to the existing development report for review.

  We appreciate your time and effort.

  Kind regards,
  Ariel H.

  0
• 

  Kazimierz Karczewski

  • July 16, 2026 17:19

  Hi Ariel,

  I wanted to give you a quick update.

  The page editing is now working correctly. Following your team's recommendations, I implemented a very limited ModSecurity configuration specific to this website and the /wp-admin/admin-ajax.php endpoint. The solution works exactly as expected while keeping ModSecurity enabled.

  Interestingly, your investigation helped uncover another issue. While implementing the ModSecurity changes, I discovered what appears to be a compatibility issue between DirectAdmin's CustomBuild ModSecurity package and Imunify360. It seems that ModSecurity has been built without Lua support, while Imunify360 deploys several SecRuleScript directives that therefore cannot be executed.

  I have already opened a technical discussion with the DirectAdmin team to determine whether this is an expected design decision or an unintended compatibility issue.

  So, what started as a Brizy support request turned into a much broader investigation. Sometimes troubleshooting infrastructure really is like a row of dominoes—fix one issue and you uncover the next one.

  Thank you again for taking the time to reproduce the problem and for forwarding it to your development team. Your findings were instrumental in resolving the issue on our production server.

  Kind regards,

  Kazik

  0

Please sign in to leave a comment.