Three years ago, a prominent WordPress security provider claimed that increasing numbers of vulnerabilities claimed to be discovered in WordPress plugins was caused not by more vulnerabilities being introduced in to them, but by better detection of old vulnerabilities. And that plugins were therefore getting more secure. It was a problematic claim to make at the time, as among other reasons, their data source simply claims that vulnerabilities have existed in all versions of a plugin. (Their data source also counted a lot of fake claims of vulnerabilities.) It continues to be problematic, as the claimed number of vulnerabilities being discovered keeps increasing.

The reality here is that many developers of WordPress plugins are continuing to introduce new vulnerable code in to their plugins. WordPress could take actions to significantly reduce that, but they are not. One method to limit the damage that those two problems cause is detecting vulnerabilities being introduced in to plugins. One method we have for doing that for our customers is a form of AI, machine learning. We now run all changes being made to plugins used by our customers through a machine learning based system trained to try to identify when vulnerabilities are introduced in those updates. That flagged a recent update to the 100,000+ install plugin Modula. In reviewing the changes made, we found that the developer had failed to include a basic security check in new code, leading to a cross-site request forgery (CSRF) vulnerability. Existing code looks to be similarly vulnerable.

The developer of the plugin, WP Chill, doesn’t have a good security track record. With another of their plugins, we warned them in January 2022 that they had incompletely fixed a vulnerability. They finally addressed that this month.

Cross-Site Request Forgery (CSRF)

Cross-site request forgery (CSRF) refers to an ability for an attacker to cause someone else to take an action they didn’t intend to. The impact depends on what action they are taking and if there might be a further vulnerability that could be exploited through that. What is more concerning when protection for that is missing is it is a strong indication that security isn’t being well handled more broadly.

Protection against CSRF was something that the security provider claimed was being handled well in new code as of three years ago, despite that not being true at the time.

The code being introduced without CSRF protection turns on a tracking feature of the plugin. The code involves a new function agree_tracking_notice() that was added to the file /includes/libraries/class-wpchill-tracking.php that is made accessible through WordPress’ AJAX functionality:

70

add_action( 'wp_ajax_agree_tracking_notice', array( $this, 'agree_tracking_notice' ) );

That function doesn’t include any security checks:

114
115
116
117

public function agree_tracking_notice() {
	update_option( $this->optin_option_name, 'true' );
	wp_die();
}

In addition to a lack of a nonce check, there isn’t a capabilities check to limit access to that function. The registration to make that function AJAX accessible only runs if a capabilities check has been passed, so it is possible the lack of a check is intentional. It also seems possible that it is lacking without the developer being aware of the issue considering other AJAX accessible functions lacking that check, don’t have it occur somewhere else before, despite needing it.

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.

After four years, the moderators have finally tacitly admitted they were behaving inappropriately and have made moves to fix the problems (though incompletely), so these full disclosures can be ended if they simply restore access to our accounts and plugins in the Plugin Directory. Hopefully that takes less than four years.

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 cause the plugin’s tracking feature to be enabled, when logged in to WordPress as an Administrator.

Replace “[path to WordPress]” with the location of WordPress.

http://[path to WordPress]/wp-admin/admin-ajax.php?action=agree_tracking_notice

Concerned About The Security of the Plugins You Use?

Plugin Security Scorecard Grade for Modula

See issues causing the plugin to get less than A+ grade