This particular WordPress issue appeared with version 5.3 and is refusing to go away. However, the problem here is not with WordPress but with the Apache ModSecurity. The particular ModSecurity rule in question is 200003 that’s been giving webmasters a headache for half a decade now.

The specific WordPress error in question is:

Post-processing of the image failed likely because the server is busy or does not have enough resources. Uploading a smaller image may help. Suggested maximum size is 2500 pixels.

You will find this error message inside wp-includes/script-loader.php:

860:            'http_error_image'          => __( 'Post-processing of the image failed likely because the server is busy or does not have enough resources. Uploading a smaller image may help. Suggested maximum size is 2500 pixels.' ),

Truth be told, this error has very little to do with server resources or the image size (as long as the image size is within your WordPress and PHP limits). This error is chiefly a result of sloppy coding.

Looking further for http_error_image, you will spot it in these two files:

wp-includes/js/plupload/handlers.js
440:                    wpQueueError( pluploadL10n.http_error_image );
449:                    wpQueueError( pluploadL10n.http_error_image );
476:                            wpQueueError( pluploadL10n.http_error_image );
509:                            wpQueueError( message || pluploadL10n.http_error_image );
518:                    wpQueueError( pluploadL10n.http_error_image );

wp-includes/js/plupload/wp-plupload.js
126:                            error( pluploadL10n.http_error_image, data, file, 'no-retry' );
135:                            error( pluploadL10n.http_error_image, data, file, 'no-retry' );
479:                            return pluploadL10n.http_error_image;

The clue to the error’s cause can be found in wp-includes/js/plupload/wp-plupload.js:

* Attempt to create image sub-sizes when an image was uploaded successfully
* but the server responded with HTTP 5xx error.

 if ( ! data || ! data.responseHeaders ) {
  error( pluploadL10n.http_error_image, data, file, 'no-retry' );
  return;
}

So it’s a 5xx error coming from the Web server. Checking the Apache logs, you will see these errors that coincide in time with your failed file upload attempts:

[Fri Feb 26 09:25:12 2021] [error] [client 192.168.122.1] 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 "39"] [id "200003"] [msg "Multipart parser detected a possible unmatched boundary."] [hostname "igoroseledko.com"] 
[uri "/wp-admin/async-upload.php"] [unique_id "YDkEyMCoeokAAAZ@JKsAAAAj"]

Open the specified location of the mod_security.conf file (/etc/httpd/conf.d/mod_security.conf in my case) and add the SecRuleRemoveById 200003 line to the end of the </IfModule> section.

Restart Apache and you should be good to go. How bad is this for your server’s security? Probably not too bad: this particular rule is known to be buggy and its value is questionable at best.