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.

All paid Patchstack users are protected from this vulnerability. Sign up for the free Community account first, to scan for vulnerabilities and apply protection for only $5 / site per month with Patchstack.

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 = '<script>' . "\n";
	$script .= "	window._tpt			??= {};" . "\n";
	$script .= "	window.SR7			??= {};" . "\n";
	$script .= "	_tpt.R				??= {};" . "\n";
	$script .= "	_tpt.R.fonts		??= {};" . "\n";
	$script .= "	_tpt.R.fonts.customFonts??= {};" . "\n";		
	$script .= "	SR7.F 				??= {};" . "\n";
	$script .= "	SR7.G				??= {};" . "\n";
	$script .= "	SR7.LIB				??= {};" . "\n";
	$script .= "	SR7.E				??= {};" . "\n";
	$script .= "	SR7.E.gAddons		??= {};" . "\n";		
	$script .= "	SR7.E.nonce			= '". wp_create_nonce('revslider_actions') ."';" . "\n";

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

	echo apply_filters('revslider_js_add_header_scripts', $script);
		
	$SR_GLOBALS['header_js'] = true;
}

Back to the save_slider, the function itself has only one purpose, to update any slider data including the slider parameter.

We then took a look at how the slider parameter display will be handled and noticed that some of the slider parameters were not properly sanitized or escaped, resulting in a possible authenticated stored XSS, since originally, the slider data could only be modified by administrator role or role that are specifically given access to the Slider Revolution feature. However, since there were quite many vulnerable slider parameters, we will not include them all in this article.

By chaining both the unauthenticated broken access control and the authenticated stored XSS on the slider parameters display, we were able to achieve unauthenticated stored XSS.

Note that this vulnerability was reproducible in a default installation and activation of the Slider Revolution plugin without a specific requirement or configuration. Since the XSS payload was placed on the targeted sliders, this vulnerability also could’ve been easily triggered by any user visiting the targeted sliders.

The patch

Since this vulnerability mainly existed because the plugin allowed any unauthenticated users to update slider data or parameters, the vendor decided to entirely remove the affected REST API endpoint. The patch can be seen below:

For the XSS case, the vendor applied proper sanitization and escaping to the affected slider data or parameters.

Conclusion

We recommend applying escaping and sanitization to any stored user input that will be displayed. Depending on the context of the data, we recommend using sanitize_text_field to sanitize value for HTML output (outside of HTML attribute) or esc_html. For escaping values inside of attributes, you can use the esc_attr function. We also recommend applying a proper permission or authorization check to the registered rest route endpoints and not providing sensitive action or process to an unauthenticated user.

Help us make the Internet a safer place

Making the WordPress ecosystem more secure is a team effort, and we believe that plugin developers and security researchers should work together.

• If you're a plugin developer, join our mVDP program that makes it easier to report, manage and address vulnerabilities in your software.
• If you're a security researcher, join Patchstack Alliance to report vulnerabilities & earn rewards.