Final resolution of this problem turned out to be that an inadvertent change by the user’s web hosting company had increased the sensitivity of security rules so that they were generating false positives and bouncing legitimate transactions.
I offered the guidance pasted below, but the issue was resolved by the webhosting company reversing their inadvertent change.
For future reference:
The error logs showed that what was happening is that a particular apache mod_security rule was triggering a false alarm and blocking the request.
ModSecurity: Access denied with code 44 (phase 2). Match of “eq 0” against “MULTIPART_UNMATCHED_BOUNDARY” required. [file “/etc/httpd/conf.d/mod_security.conf”] [line “34”] [id “xxxx”] [msg “Multipart parser detected a possible unmatched boundary.”] [hostname “XXXXXXX.com”] [uri “/wp-admin/admin-ajax.php”] [unique_id “XXXXXXXXXXXXXX”], referer: https://XXXXXXXX.com/wp-admin/admin.php?page=wp-issues-crm-main&entity=advanced_search&action=new_blank_form&id_requested=0
If you google parts of this phrase, you will see that it is not an uncommon problem with multiple applications. This security rule does trigger false positives.
The solution is to downgrade the response to this particular rule (“MULTIPART_UNMATCHED_BOUNDARY”) firing from ‘block’ to ‘log’.
In fact, the relevant mod_security documentation recognizes the possibility of false positives and suggest the solution here:
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v2.x%29#MULTIPART_UNMATCHED_BOUNDARY
Basically, the fix is to modify one line in the mod_security configuration file to set the variable MULTIPART_UNMATCHED_BOUNDARY as follows:
SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \
"phase:2,id:31,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.'"
It would appear that you just want to REMOVE the word “deny” from this rule line, but check mod_security documentation.
https://support.kemptechnologies.com/hc/en-us/articles/209635223-How-to-write-a-WAF-rule-Modsecurity-Rule-Writing