One of the expanding capabilities of our new Plugin Security Scorecard is the ability to identify software libraries included in WordPress plugins. From there, if there are known vulnerabilities in those libraries in the plugins, that can be warned about when plugins are graded. We can also go back and check if previous checks identified if plugins contained a vulnerable version of those libraries. As we found when adding a library to that checking last week, there is a need to better monitor this situation. That is because we found that a plugin with 600,000+ installs, MetaSlider, is still using a vulnerable version of the AppSero Client library. The vulnerability was fixed 17 months ago. We reached out the developer of that plugin last week as well. They said a fix will be included in the next release of the plugin, which they said might come out this week. (It hasn’t as of us publishing this post.)

The situation highlights other areas where security could be improved.

GitHub Advisory Missing

Despite the vulnerability having been fixed and acknowledge to have been a vulnerability by the developer, the GitHub project for it doesn’t have any published security advisories shown:

(The page also says the developer doesn’t have a security policy for the library.)

Inaccurate Vulnerability Information From Developer and Wordfence

Another problem is the inaccurate information from both the developer and Wordfence as to what versions of the library actually contained the vulnerability.

The changelog for version 2.0.1 of the plugin reads:

• fix: Broken Access Control Vulnerability Issue by @nurul-umbhiya in #36
• fix: Broken Access Control Vulnerability Issue by @anisAronno in #37

We found that there was a capability check being added to a function, but there was already a nonce check in place and to get access to the nonce, you needed to pass the same capability check. While a nonce check isn’t intended for that purpose, it would normally have the same impact.

Looking at older versions, we found that version 1.2.3 had a changelog entry about a vulnerability fix as well. Though vaguer, “Fix for a security vulnerability.” That is related to this vulnerably or at least the vulnerability was partially fixed in that version. That version was released in March 2023.

Looking at the commit that added a missing nonce check, the developer was apparently addressing issues identified by PHP CodeSniffer (PHPCS) (and presumably the WordPress Coding Standards for that.) Unfortunately, there wasn’t a capability check added. That is something a good security review would have caught. (We just completed a review of plugin where we identified multiple instances with similar code where one of both the checks was missing.) As we noted recently, the limitations of what PHPCS and the WordPress Coding Standards for that can deliver when it comes to security are being noted by the developers.

The previously vulnerable code runs during admin_init, which makes it accessible to even those not logged in to WordPress:

168

add_action( 'admin_init', array( $this, 'handle_optin_optout' ) );

That function handles enabling or disabling tracking and calls other functions to do that. As of version 1.2.2, it didn’t include any security checks:

464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479

public function handle_optin_optout() {
 
	if ( isset( $_GET[ $this->client->slug . '_tracker_optin' ] ) && $_GET[ $this->client->slug . '_tracker_optin' ] == 'true' ) {
		$this->optin();
 
		wp_redirect( remove_query_arg( $this->client->slug . '_tracker_optin' ) );
		exit;
	}
 
	if ( isset( $_GET[ $this->client->slug . '_tracker_optout' ] ) && $_GET[ $this->client->slug . '_tracker_optout' ] == 'true' ) {
		$this->optout();
 
		wp_redirect( remove_query_arg( $this->client->slug . '_tracker_optout' ) );
		exit;
	}
}

In the next version, a nonce check was added:

464
465
466
467
468
469
470
471

public function handle_optin_optout() {
	if ( ! isset( $_GET['_wpnonce'] ) ) {
		return;
	}
 
	if ( ! wp_verify_nonce( sanitize_key( $_GET['_wpnonce'] ), '_wpnonce' ) ) {
		return;
	}

Then, in version 2.0.1, a capability check was added:

489
490
491
492
493
494
495
496
497
498
499
500
501

public function handle_optin_optout()
{
	if (!isset($_GET['_wpnonce'])) {
		return;
	}
 
	if (!wp_verify_nonce(sanitize_key($_GET['_wpnonce']), '_wpnonce')) {
		return;
	}
 
	if (!current_user_can('manage_options')) {
		return;
	}

Wordfence, despite their CEO claiming that their data is “impeccable,” incorrectly claimed that version 2.0.1 of the library fixed the vulnerability by adding a nonce check. They also missed that the most popular plugin using the library, MetaSlider, is using the library and using a vulnerable version of it.

Developers Not Vetting Libraries

As is often the case with WordPress plugin developers, the developer of this plugin claims to be addressing security issues well:

We do our best at MetaSlider to solve all security issues. We aim to develop, test, release and announce patches as quickly as possible after issues have been discovered.

Beyond the problem here of not updating the vulnerable library in 17 months or even updating it outside of knowing it is vulnerable for 24 months, the vulnerability would have been caught during a decent security review of the plugin or the library. Unfortunately, as this plugin is yet another reminder of, plugin developers are often not vetting third-party code being incorporated into their plugins. With another library, even a vulnerability being widely exploited in the library didn’t cause developers incorporating it to vet the security.