POST requests return HTTP 400 after wafcl_module is enabled in Imunify360 WebShield

Issue

After wafcl_module is enabled, HTTP requests containing a request body (such as POST, PUT, or PROPFIND) fail with HTTP 400 Bad Request.

Environment

• Imunify360
• cPanel/WHM
• Apache
• lsapi
• WordPress logins 
• WooCommerce checkout and AJAX requests 
• Contact forms 
• XML-RPC 
• WebDAV 
• Other applications that submit HTTP request bodies

Solution

This is a known issue under investigation by our development team under DEF-49326.

As a supported workaround, disable the WebShield feature flags:

imunify360-agent config update '{"WEBSHIELD": {"use_feature_flags": false}}'

After applying the configuration, verify that POST requests are processed normally.

Note

Renaming or removing wafcl.conf is not the supported solution because the file may be recreated during future Imunify360 or cPanel updates.

The configuration above is stored in the Imunify360 configuration and persists across package updates. It is currently the recommended mitigation until a permanent fix becomes available.

Cause

During initial boot after installation, Imunify360 activated the wafcl_module via an internal feature flag (WEBSHIELD.use_feature_flags: true). This module loaded into Apache and intercepted POST request bodies before forwarding to the LSAPI backend. Under server load, the module consumed the request body, leaving LSAPI with no content — resulting in 400 responses to clients. The 507 errors observed when ModSecurity was disabled represented a backend issue exposed when ModSecurity's body processing was removed.