You’re hijacking calls to amin-ajax.php that are not for you.

Hi Eli,

Thank you for reporting this. The team will take a look at it and investigate.

Kind regards,

Thanks for the quick reply. Please let me know when you have it fix or if there is anything else you need from me.

Hello Eli,

David here.

I got in touch with one of our developers and he was wondering with what plugin is the issue occurring?
You mentioned “my plugin” in your initial message, to what plugin are you referring to if it’s not too much trouble?
Because he says that, the function of the Worker only reacts if the request has support_mwp_message in it, which is meant for us.

Waiting for your reply.

My plugin is https://www.ads-software.com/plugins/gotmls/

…and this only seems to be a problem when there are known threats (infected files) on the user’s site and they try to clean them using the Automatic fix feature in my plugin.

The form that my plugin posts should look something like this:

<form method="POST" action="/wp-admin/admin-ajax.php?GOTMLS_mt=[MD5_HASH]&page=GOTMLS-settings" target="GOTMLS_iFrame" name="GOTMLS_Form_clean"><input type="hidden" name="action" value="GOTMLS_fix"><input type="hidden" id="GOTMLS_fixing" name="GOTMLS_fixing" value="1"><input type="hidden" name="GOTMLS_mt" value="[MD5_HASH]"><input type="hidden" name="scan_type" value="Complete Scan"><input type="hidden" name="check[]" value="db_scan"><input type="hidden" name="check[]" value="htaccess"><input type="hidden" name="check[]" value="timthumb"><input type="hidden" name="check[]" value="known"><input type="hidden" name="check[]" value="wp_core"><input type="hidden" name="scan_what" value="0"><input type="hidden" name="scan_depth" value="-1"><input type="hidden" name="exclude_ext" value="png,jpg,jpeg,gif,bmp,tif,tiff,psd,svg,webp,doc,docx,ttf,fla,flv,mov,mp3,pdf,css,pot,po,mo,so,exe,zip,7z,gz,rar"><input type="hidden" name="exclude_dir" value="">
<input type="checkbox" name="GOTMLS_fix[]" value="[BASE64_HASH]" checked="known">
</form>

… but several clients that use both of our plugins together report that they receive the response

{“success”:false,”message”:”Please enter a message.”}

when submitting this form unless they deactivate your plugin.

I have looked at your code and it does appear that your intention is to only respond if support_mwp_message is passed …

if (!isset($request->request['support_mwp_message']) || !is_scalar($request->request['support_mwp_message'])) {
   return;
}

… and yet somehow this code on line 205 of /src/MWP/EventListener/PublicRequest/BrandContactSupport.php in your plugin does execute on these user’s sites instead of my action hook’s response.

I have been unable to recreate this issue on any of my test sites because I don’t know what conditions would have your plugin activating the enableContactSupport function in you plugin which must be inadvertently adding this support_mwp_message value to the post or at least somehow creating the empty scalar value $request->request[‘support_mwp_message’] which slips through your conditions and returns the false response message.

I also don’t know how you would recreate this issue on your end unless you had real infections on one of your test sites so that you could try using my plugin to clean them. Maybe we can work together to recreate this scenario, or maybe it would just be better if your developer closed the loophole that is permitting an empty scalar value of support_mwp_message to slip through the cracks. Maybe the if statement on line 184 of /src/MWP/EventListener/PublicRequest/BrandContactSupport.php mentioned above should read like this:

if (!isset($request->request['support_mwp_message']) || empty($request->request['support_mwp_message'])) {
   return;
}

Hi Eli,

Just a quick update: since this is very specific, our developers will try to create a test case with all the additional info you’ve provided and see what’s going on.

We’ll reply here once we have more info.

Kind regards,

In my particular case it is very specific, yes. However, there is a potential that the code loophole that I outlined about could interfere with other plugin in other cases as well. I’m not sure that you will even be able to recreate the exact scenario that I have been made aware of by my clients and have yet to recreate myself. So wouldn’t it be easier and more preemptively solution oriented to just close hole in the condition that allows this erroneous message to to be returned?

I don’t know how but there is obviously some conditions present in the wild that are resulting in an empty scalar value of support_mwp_message being passed along and your function is hooked into the admin init action so it responds and kills the page before my ajax-admin hook can respond. I propose that you either change your return condition to include empty support_mwp_message values as well as non-scalar values so that you don’t return this “Please enter a message” response or find another way to safely exit your handleSupportForm function if the admin_init is called from any calls to admin-ajax.php that does not have your own ajax action hook. Is there any reason why neither of these two proposed fixes would sound reasonable to your developers?