On Monday, we discussed testing we did to see what WordPress firewall plugins were able to protect against a fixed vulnerability that has been exploited in the WordPress plugin tagDiv Composer. We also noted that the best solution was to update the plugin to the latest version, as this was fixed before the exploitation was happening. We subsequently had a new customer for our service contact us who mentioned they were unable to update things, as updating a connected theme was causing the website to break. With most WordPress plugin vulnerabilities, it is relatively easy to patch the code enough to stop exploitation of the vulnerability. That is true for this vulnerability, as we found when we looked into providing them such a patch.

A proof of concept for the vulnerability shows, the exploitation happens through the REST API route /tdw/save_css. At least in the version being used by our customer, 2.7, the relevant code for that route exists in the plugin’s file /css-live/includes/td_live_css_ajax.php. The registration for the route occurs in the function td_live_css_on_rest_api_init():

12
13
14
15
16
17
18

function td_live_css_on_rest_api_init() {
	$namespace = 'tdw';
	register_rest_route($namespace, '/save_css/', array(
		'methods'  => 'POST',
		'callback' => 'td_live_css_on_ajax_save_css',
		'permission_callback' => '__return_true',
	));

The line right above that causes that function to run:

11

add_action( 'rest_api_init', 'td_live_css_on_rest_api_init');

By commenting out that line, like this, access to that REST API route is disabled:

11

//add_action( 'rest_api_init', 'td_live_css_on_rest_api_init');

That stops hackers from being able to access the vulnerable code through the route.

In that version of the plugin we reviewed, the code is also called elsewhere, in a way that looks to not be properly secured, but not in an exploitable way.

Another option to handle this would be to change the function that is called when accessing the REST API route, td_live_css_on_ajax_save_css() in the same file. That function contains code contain that updates a WordPress setting, which the hacker places malicious code in. You can cause the existing code in that to not run by adding a return to the first line of the function:

26
27

function td_live_css_on_ajax_save_css(WP_REST_Request $request) {
	return;

A similar approach is to do a conditional stop the code from running based on if a user has a certain capability, as we showed with another recent vulnerability that appeared to be targeted by a hacker.

Similar approaches can be used with other vulnerable code in WordPress plugins. Your best option with this approach is to have someone knowledgeable with WordPress plugin security to provide you with relevant code. Otherwise, you can try using a proof of concept in a test environment to see if the code is stopping exploitation.