Unauthenticated XSS Vulnerability Patched in Slider Revolution Plugin

Slider Revolution came to us with a request to audit their product for potential vulnerabilities since they wanted to make sure that their users’ websites were not vulnerable to an attack.

This blog post discusses our audit findings, which we have been authorized to publicize. If you’re a Slider Revolution user, please update the plugin to version 6.7.11 or higher.

Patchstack users are protected from this vulnerability.

For plugin developers, we have security audit services and Enterprise API for hosting companies.

About the Slider Revolution Plugin

Slider Revolution is a premium WordPress plugin and has more than 9 million active users. Used by everyone — from self-starting business owners to tech-savvy web developers — Slider Revolution continues to be one of the most popular plugins for WordPress.

While Slider Revolution may have got its start as a responsive slider plugin, users are now able to create anything from animated hero images, 3D carousels, split-screen content, one-page websites, and designs you won’t find anywhere else.

The security vulnerability

This plugin experienced an unauthenticated stored XSS vulnerability. As a result, it could have allowed any unauthenticated user to steal sensitive information to, in this case, privilege escalation on the WordPress site by performing a single HTTP request.

This vulnerability occurred because the code that handles input from the user didn’t implement sanitization and output escaping on the slider’s parameter data. This case also combined with broken access control on one of the available REST API endpoints from the plugin which allowed unauthenticated users to update slider data.

Chaining both of these conditions, we were able to achieve unauthenticated stored XSS on the plugin. The unauthenticated broken access control vulnerability itself is fixed on version 6.7.0 and assigned CVE-2024-34444. For the authenticated stored XSS itself, it is fully fixed on version 6.7.11 and assigned CVE-2024-34443.

The main vulnerability, which is unauthenticated broken access control, existed in the function init_rest_api:

public function init_rest_api(){
	/**
		WP_REST_SERVER::READABLE = 'GET'
		WP_REST_SERVER::CREATABLE = 'POST'
		WP_REST_SERVER::EDITABLE = 'POST, PUT, PATCH'
		WP_REST_SERVER::DELETABLE = 'DELETE'
		WP_REST_SERVER::ALLMETHODS = 'GET, POST, PUT, PATCH, DELETE'
			return $_SERVER['REQUEST_METHOD']
	**/

------- CUT HERE -------

	register_rest_route('sliderrevolution', '/sliders', array(
		'methods'				=> WP_REST_SERVER::CREATABLE,
		'show_in_index'			=> false,
		'callback'				=> array($this, 'save_slider'),
		'permission_callback'	=> array($this, 'check_nonce'),
	));
}

There is a custom REST API endpoint pointing to the save_slider function with the permission_callback set to the check_nonce function. Let’s take a look at the check_nonce function:

public function check_nonce(){
	$this->setup_exception_handler();
	$nonce	= $this->get_request_var('nonce');
	$nonce	= (empty($nonce)) ? $this->get_request_var('rs-nonce') : $nonce;
	if(wp_verify_nonce($nonce, 'revslider_actions') == false){
		//check if it is wp nonce and if the action is refresh nonce
		$this->ajax_response_error(__('Bad Request', 'revslider'));
		exit;
	}

	return true;
}

Notice that there was no permission check on the check_nonce function, however, it only implemented a nonce value check of revslider_actions. After observation, we noticed that the nonce value could be fetched by an unauthenticated user. One of the functions to display the nonce value to an unauthenticated user is the js_add_header_scripts function:

public function js_add_header_scripts(){
	global $SR_GLOBALS;

------- CUT HERE -------

	$script = '