Yesterday, we had what would appear to be a hacker probing for usage of the WordPress plugin Checkout Mestres WP on our website by requesting the readme.txt file for it like this:

/wp-content/plugins/checkout-mestres-wp/readme.txt

What would explain their interest in that plugin? Well, the plugin was closed on March 27, which could suggest that there is a vulnerability in it:

On March 31, the developer submitted an update for the plugin, which involved them adding a capability check to limit access to some code to only users with the manage_options capability. That capability is normally only accessible to Administrators. Someone knowledgeable with the handling of security of WordPress plugins, looking at the code changed, would understand the significance of that. They would also understand that the code is still vulnerable, though less vulnerable.

For those not knowledgeable, they were told by Wordfence three days before how this could be weaponized:

The Checkout Mestres do WP for WooCommerce plugin for WordPress is vulnerable to unauthorized modification of data that can lead to privilege escalation due to a missing capability check on the cwmpUpdateOptions() function in versions 8.6.5 to 8.7.5. This makes it possible for unauthenticated attackers to update arbitrary options on the WordPress site. This can be leveraged to update the default role for registration to administrator and enable user registration for attackers to gain administrative user access to a vulnerable site.

While it can be debated if disclosing that information was right to do, what can’t really be debated is that Wordfence should have worked with the team running the WordPress Plugin Directory to make sure a fix was available before that type of disclosure. Instead, the 600 or so websites using the plugin have been exposed to be exploitable. That isn’t bad for Wordfence, since they could sell those websites their $600 a year hack cleanup service.

We have offered for years to do most of the work needed to make sure situations like this don’t happen, but the team running the plugin directory has steadfastly refused to accept our help or take it on by themselves. Wordfence has been notably silent about all of that, which makes sense when you understand their business model. They are not alone in that, as other security providers, including one owned by Automattic, WPScan, have given further exposure to that information about the vulnerability without insisting that it get a fix.

How much work would be required to have avoided this situation? Almost none.

The simplest option here would be to make the chance the developer already made on the 31st and provide that as an update for those already using plugin. The first part of that has happened, the latter hasn’t happened. That is, even though the team running the plugin directory can provide the update without making the plugin available to others. It is a capability they have had for at least a decade, but strangely, don’t take advantage of. As can be confirmed with the previous version installed on a WordPress website:

Plugin Actually Got More Insecure

In August 2021, the Matt Mullenweg owned WP Tavern had a post where a Wordfence employee was quoted, claiming that WordPress plugins were getting more secure and that most vulnerabilities being found were old:

Both Wordfence and WPScan claim that the greater number of vulnerabilities reported this year is indicative of the growth of the WordPress ecosystem and a maturing, healthy interest in security. Themes and plugins aren’t getting more insecure over time but rather there are more people interested in discovering and reporting vulnerabilities.

“First and foremost, we aren’t seeing a lot of newly introduced vulnerabilities in plugins and themes but rather we are seeing a lot of older vulnerabilities in older plugins and themes being reported/fixed that just weren’t detected until now,” Wordfence Threat Analyst Chloe Chamberland said.

“Vulnerabilities aren’t being introduced as frequently and more vulnerabilities are being detected simply due to the higher activity of researchers which is in turn positively impacting the security of the WordPress ecosystem. Considering it isn’t newly introduced vulnerabilities that are being frequently discovered, I feel confident in saying that the increase in discoveries doesn’t indicate that the ecosystem is getting less secure at all but rather getting more secure.”

Chamberland also said she believes there is a domino effect when vulnerabilities are disclosed to vendors and they learn from their accidents, causing them to develop more secure products in the future.

Contrary to that claim (and actual evidence at the time), this vulnerability was only introduced in to the plugin in September. How insecure the code is also contradicts that vendors learn from “accidents” that other developers have.

The Vulnerable Code

The attempt to fix the vulnerability was made in the function cwmpUpdateOptions() in the file /backend/core/base/ajax.php. In that file, the function is made accessible through WordPress’ AJAX functionality to those logged in to WordPress:

29

add_action( 'wp_ajax_cwmpUpdateOptions', 'cwmpUpdateOptions' );

And to those not logged in:

30

add_action( 'wp_ajax_nopriv_cwmpUpdateOptions', 'cwmpUpdateOptions' );

Here is how the function looked before the change:

31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

function cwmpUpdateOptions() {
    if (isset($_POST['data'])) {
        parse_str($_POST['data'], $parsed_data);
        $campos_com_html = array('cwmp_remember_password_body', 'parcelas_mwp_payment_second_pre', 'parcelas_mwp_payment_list_format_s_juros', 'parcelas_mwp_payment_list_format_c_juros');
        foreach ($parsed_data as $campo => $valor) {
            if (in_array($campo, $campos_com_html)) {
                $safe_value = $valor;
            } else {
                $safe_value = sanitize_text_field($valor);
            }
            update_option(sanitize_text_field($campo), $safe_value);
        }
        echo "Opções atualizadas com sucesso.";
    } else {
        echo "Nenhum dado foi enviado.";
    }
 
    wp_die();
}

The function allows updating arbitrary WordPress options (settings). You don’t have to be a security expert to know that someone not logged in to WordPress shouldn’t be able to do that.

The change made was to limit access to the functionality to Administrators:

31
32
33
34

function cwmpUpdateOptions() {
    if ( ! current_user_can( 'manage_options' ) ) {
        wp_send_json_error( 'Acesso negado.', 403 );
    }

The code still is lacking protection against cross-site request forgery (CSRF), so there is still a vulnerability.

Code that allows updating arbitrary options really shouldn’t exist in a plugin like this. Instead, only intended options should be updateable.

More Vulnerabilities Probably Exist

Based on a quick check of the code it looks like there are more vulnerabilities in the code.

Free Warning

As the vulnerability is being targeted by a hacker, we are adding accurate data on it to the free data that comes with our Plugin Vulnerabilities plugin.