WordPress Security Community’s Poor Results on Display With Failed Fix of Vulnerability in 3+ Million Install Plugin MonsterInsights

A couple of weeks ago WordPress security provider WPScan, which is controlled by the head of WordPress Matt Mullenweg, claimed that an authenticated persistent cross-site scripting (XSS) vulnerability involving its Inline Popular Posts block had been fixed in the latest version, 8.12.1, of the 3+ million install plugin MonsterInsights:

That is a plugin from Awesome Motive, which makes this more notable, as that company’s Chief Security Officer, Chris Christoff, is also the Security Reviewer for the team running the WordPress’ plugin directory. In that role, he is sponsored by Awesome Motive. (He also claims to be a member of the “WordPress Core Security team”.) Last month we noted that he seems to be failing miserably in that reviewer role, something that Awesome Motive didn’t have any response for. That makes what we found with the MonsterInsights less surprising.

As at least one of our customers uses the plugin, we starting looking into the claim to see if there really had been a vulnerability and it had been fixed.

The only changelog entry for version 8.12.1 in no way suggested that the vulnerability had been fixed:

Fix: We made updates to authentication

Looking at the changes made in that version, we were unable to figure out how the claimed vulnerability could have been fixed in that version. Despite those issues, other providers parroted WPScan’s claim. Here was Wordfence repeating the claim:

And Patchstack:

Last Friday, WPScan released a proof of concept for the vulnerability. With that we were able to figure out that the vulnerability was actually attempted to be fixed in version 8.12.0. Awesome Motive didn’t disclose that in the changelog:

Enhancement: We updated and fixed some UI/UX elements to make MonsterInsights easier to use

Enhancement: We optimized our Javascript code to work better with minification plugins

Enhancement: We optimized our Javascript code to work better with minification plugins

Enhancement: We optimized the Javascript code to work nicely with minification plugins

Enhancement: We optimized our code to work better with PHP8

That lack of disclosure is troubling coming from a company whose security head is also a member of the teams handling security for WordPress.

But things get worse from there, as we found that the vulnerability was only partially addressed.

The attempted fix involved adding escaping to two lines in the file /lite/includes/popular-posts/class-popular-posts-inline.php. One of those involves changing this line:

90	$html .= '<span class="monsterinsights-inline-popular-posts-label" ' . $this->get_element_style( $theme, 'label', $atts ) . '>' . $label_text . '</span>';

That was changed to add escaping:

90	$html .= '<span class="monsterinsights-inline-popular-posts-label" ' . esc_textarea($this->get_element_style( $theme, 'label', $atts )) . '>' . esc_textarea($label_text) . '</span>';

But taking a wider view, you can see a problem as the next two chunks of code are similar to that, but lack the escaping as of the latest version, 8.12.1:

if ( ! empty( $theme_styles['styles']['label'] ) ) {
	$html .= '<span class="monsterinsights-inline-popular-posts-label" ' . esc_textarea($this->get_element_style( $theme, 'label', $atts )) . '>' . esc_textarea($label_text) . '</span>';
}
if ( ! empty( $theme_styles['styles']['border'] ) ) {
	$html .= '<span class="monsterinsights-inline-popular-posts-border" ' . $this->get_element_style( $theme, 'border', $atts, 'color' ) . '></span>';
}
if ( ! empty( $theme_styles['styles']['border']['color2'] ) ) {
	$html .= '<span class="monsterinsights-inline-popular-posts-border-2" ' . $this->get_element_style( $theme, 'border', $atts, 'color2' ) . '></span>';
}

Looking at the other line changed, shows more of the problem, as the developer only added escaping in one of two places they should have:

78	$html = '<div class="' . esc_textarea($this->get_wrapper_class( $atts )) . '" ' . $this->get_element_style( $theme, 'background', $atts ) . '>';

We confirmed that the vulnerability is still exploitable because of that. We have notified the developer of that and offered to help them address it.

Another problem here is that the wrong escaping function is being used, as esc_attr() should be used to escape HTML attributes, not esc_textarea().

Yet another problem here, is that the insecurity still also exists in the Popular Posts block as well.

How Things Can be Improved

Clearly, things haven’t gone right here, and improvements could be made to limit this type of situation in the future.

One improvement would be for security providers to promptly provide details of claimed vulnerabilities, so their claims can be independently confirmed. Another approach for this would be for WordPress to have a system where plugin developers can report the details of vulnerabilities being fixed and that information could then be provided to a trusted group to review to make sure that vulnerabilities have been fixed.

WPScan tries to get people to report vulnerabilities to them instead of directly to developers or to WordPress, which is a big problem when they don’t do the checking they should do. WordPress could take a stance against that type of activity, but that is unlikely to happen when the head of WordPress also runs a company doing that.

If the developer had disclosed that there was a security fix being made in the version this was attempted to be fixed, we could have reviewed the changes and found the issue earlier. WordPress could require that developers clearly disclosed vulnerabilities.

The three vulnerability data providers we mentioned as having gotten this wrong are also the source of the data used by many other WordPress security providers (though that often isn’t disclosed). These providers are not honest about the quality of the data. For example, Patchstack claims that their data is “Hand curated, verified and enriched vulnerability information by Patchstack security experts”, despite them not actually verifying data, as can be seen here. If you need access to this type of data, you should find a provider that actually does the verification work, otherwise, the data is largely useless, as can be seen with with happened here.

It’s hard to look at this situation and come away feeling good about what is going on with the team running the WordPress Plugin Directory, considering their security reviewer appears to be unfit for the position. That team has long been in need of oversight, as among the many problems with them, currently they are blocking others looking to join the team, who could help fix the problems that continue unabated, from doing that.