AI Helps to Detect Incomplete Security Fix Being Made to 1+ Million Install WordPress Plugin WP File Manager

We often find that attempts to fix vulnerabilities in WordPress plugin have been incomplete or failed entirely, including with vulnerabilities could certainly be targeting. For us to be able to find that, we have to know that a vulnerability was supposed to have been fixed. Developers don’t always disclose that vulnerabilities have been fixed. While that could be defensible in limited circumstances for serious vulnerabilities likely to be exploited, it usually isn’t that situation when it happens. One method we have to determine that vulnerabilities have been attempted to be fixed is using machine learning, a form of artificial intelligence (AI), to try to detect relevant changes being made to the code of plugin in the WordPress Plugin Directory. That monitoring flagged just such a change made yesterday to the 1+ million install plugin WP File Manager. The changelog for the change wouldn’t suggest a security fix as it reads, “Fixed Language issue.”

Looking at the changes made, it isn’t hard to see why it was flagged, as a nonce check, which prevents a type of vulnerability, cross-site request forgery (CSRF), was being added:

849	if( isset( $_GET['lang'] ) && !empty( $_GET['lang'] ) && !wp_verify_nonce( isset( $_GET['nonce'] ) ? $_GET['nonce'] : '', 'wp-file-manager-language' )){

What that was added to was code to change the language that the plugin displays the file manager in. As part of setting the language, part of the location of a JavaScript file to be loaded is set. If an attacker had some ability to load JavaScript files on the website, it could be combined with this to cause this that file to be loaded in the context of an Admin area of WordPress.

As part of reviewing this, we checked to make sure there was no similar code in the plugin that is still vulnerable. Unfortunately, we found that related code to set the theme used for the file manager still lacks a nonce check:

$theme = isset($_GET['theme']) && !empty($_GET['theme']) ? sanitize_text_field(htmlentities($_GET['theme'])) : '';
// New Theme
if (!empty($theme)) {
	delete_transient('wp_fm_theme');
	set_transient('wp_fm_theme', $theme, 60 * 60 * 720);
	if ($theme != 'default') {
		wp_enqueue_style('theme-latest', plugins_url('lib/themes/'.$theme.'/css/theme.css', __FILE__), '', $this->ver);
	}
}

We reached out to the developer about that yesterday and got what seemed to be a canned response. So far, the rest of the issue hasn’t been addressed.