WP Engine Didn’t Disclose They Were Fixing Vulnerability in 200,000+ Install WordPress Plugin

Recently, the WordPress security provider Patchstack claimed that a cross-site request forgery (CSRF) vulnerability had been fixed in the 200,000+ install WordPress plugin PHP Compatibility Checker. Patchstack has a track record of providing inaccurate information on vulnerabilities in WordPress plugins, so you can’t take them at their word that there really was a vulnerability or that it has been fixed. Unfortunately, they also don’t provide basic information to double check their claims. In this case, they provide this description of what CSRF as the “details” of the vulnerability:

Mika discovered and reported this Cross Site Request Forgery (CSRF) vulnerability in WordPress PHP Compatibility Checker Plugin. This could allow a malicious actor to force higher privileged users to execute unwanted actions under their current authentication. This vulnerability has been fixed in version 1.6.0.

That plugin is developed by WP Engine. As we noted a couple of weeks ago, when warning about a CSRF vulnerability in brand new plugin from them, they appear to have a reputation for having a good handle on security, despite having a bad track record going back many years. If they really had a good handle on security, you would expect that they wouldn’t have vulnerabilities like this in their plugins, but if they did have one, they would disclose it when it was fixed. Here are the changelog entries for version 1.6.0 of the plugin, which Patchstack claimed had fixed the CSRF vulnerability:

Changed from running PHP Compatibility scans on your WordPress server to using scan data from Tide.

Removed phpcompat WP-CLI command.

Update dependencies.

Nothing in that suggests that a security issue was addressed in that version. In checking into this, we found that a CSRF vulnerability was addressed in the new version. Presumably that is what Patchstack is referring to, but we don’t know for sure. So there still could be that type of vulnerability in the plugin.

Looking at the changes being made in that version, we didn’t find any code being added to protect against CSRF. Installing the previous version of the plugin, we found that in that version there wasn’t protection against CSRF when running a scan through the plugin. As suggested by the first changelog entry, the scan process was changed in the new version and that removed the CSRF vulnerability as the scan process was changed.

As of the previous version, there were three AJAX accessible functions in the plugin. One of those started the scan. That was registered to be accessible to those logged in to WordPress:

88	add_action( 'wp_ajax_wpephpcompat_start_test', array( $instance, 'start_test' ) );

That function has a capabilities check to limit who has access to it, but it doesn’t include a nonce check to prevent CSRF:

public function start_test() {
	if ( current_user_can( WPEPHPCOMPAT_CAPABILITY ) || ( defined( 'DOING_CRON' ) && DOING_CRON ) ) {
		global $wpdb;
 
		$wpephpc = new WPEPHPCompat( dirname( __FILE__ ) );
 
		$test_data = array();
		foreach ( array( 'test_version', 'only_active' ) as $key ) {
			if ( isset( $_POST[ $key ] ) ) {
				$test_data[ $key ] = sanitize_text_field( $_POST[ $key ] );
			}
		}
 
		// New scan!
		if ( isset( $_POST['startScan'] ) ) {
			// Make sure we clean up after the last test.
			$wpephpc->clean_after_scan();
 
			// Fork so we can close the connection.
			$this->fork_scan( $test_data['test_version'], $test_data['only_active'] );
		} else {
			if ( isset( $test_data['test_version'] ) ) {
				$wpephpc->test_version = $test_data['test_version'];
			}
 
			if ( isset( $test_data['only_active'] ) ) {
				$wpephpc->only_active = $test_data['only_active'];
			}
 
			$wpephpc->start_test();

So an attacker could cause someone that is allowed to access that function or the other two to cause them to run without them intending it. Unless there was an additional security issue that could be accessed through those functions, the impact of the vulnerability is rather limited.

Those functions were removed in version 1.6.0.

In determining what version of the plugin were vulnerable, so that we could correctly warn our customers of which version are vulnerable, we found WP Engine had not clearly disclosed a previous related vulnerability fixed, as they disclosed a vulnerability was being fixed with this changelog entry: “Added additional role protections”.