Last week, we had someone contact us about addressing an unfixed vulnerability in a WordPress plugin. In taking a quick look at that, we found the vulnerability had been fixed over three years ago. So why was this person asking about that now? Well, it turned out in part, that the security provider Patchstack, as is often the case, didn’t vet the information they simply copied from another provider.

Based on the name they used for the vulnerability, we could determine that Patchstack is the original source for this person’s information. Whether they got it directly from Patchstack or from someone in turn using their data, we don’t know. If you look at Patchstack’s listing for the relevant vulnerability, they don’t provide even basic information about the vulnerability. But they did say that it hadn’t been fixed and was in version 4.7 of the plugin.

If you head over to the listing for the plugin St-Daily-Tip, you can see the most recent version is 4.8:

You can also see that it was closed in 2021.

The changelog for version 4.8 lists that version as having “Security Fixes.”

You can see that Wordfence has a listing with more information. Though, still not the relevant vulnerable code or a proof of concept, to easily check on what is supposed to be at issue and if it is fixed.

Both of them copied their information from WPScan. WPScan provides a proof of concept with their listing. If you try that with version 4.8, it doesn’t work. If you look at the changes made in version 4.8 that makes sense, as that added a nonce check to the relevant code, which prevents cross-site request forgery (CSRF). The vulnerability involved CSRF, so addressing that fixed the vulnerability. There still should have been some form of sanitization, validation, or escaping done as well.

Version 4.8 was released before any of them published their information, so the lack of checking if the vulnerability was fixed isn’t explained by the fixing coming out after their information was published.

While the plugin is closed, it is possible to get version 4.8 and update to that, but that doesn’t solve all the security problems with the plugin.

Still Vulnerable to CSRF

The code changes is in the file /st-daily-tip-admin.php. The new code looks like this:

644
645
646
647
648
649
650
651

if (isset($_REQUEST['default_text'])){
	$nonce = $_REQUEST['_wpnonce'];
	if ( ! wp_verify_nonce( $nonce, 'default_text_nonce' ) ) {
	  exit; // Get out of here, the nonce is rotten!
	}
 
	update_option("st_daily_default_text", $_REQUEST["default_tip"]);	
}

The code immediately after that is still vulnerable to CSRF. There wasn’t a nonce check added and user input is passed directly in to a SQL statement, so there is cross-site request forgery (CSRF)/SQL injection vulnerability:

653
654
655
656
657
658
659
660
661

if (isset(A WordPress Plugin Vulnerability Might Have a Fix Even if Security Providers Say That One Doesn’t Exist) && isset($_REQUEST['edit_id'])) {
	global $wpdb;
	global $table_suffix;
 
	$table_suffix = "dailytipdata";
	$table_name = $wpdb->prefix . $table_suffix;
 
	$id = st_daily_tip_check_input($_REQUEST["edit_id"]);
	$edit_tip = $wpdb->get_row("SELECT * FROM $table_name WHERE id='$id';", ARRAY_A);

The code does pass the user input through a function, but that simply trims spaces from the beginning and end of the input and removes slashes:

15
16
17
18
19
20
21

function st_daily_tip_check_input($data)
{
    $data = trim($data);
    $data = stripslashes($data);
 
    return $data;
}

Best Protecting Against Unfixed WordPress Plugin Vulnerabilities

CSRF vulnerabilities involve causing someone else to take action they didn’t intend to. This could be used in a targeted attack, but the vast majority of WordPress websites are not at threat of a targeted attack. So these vulnerabilities in this plugin are not really something to worry about for most websites.

For those that have plugins that have vulnerabilities that are not being addressed and need to ensure they are protected against. The best solution is to fix the vulnerabilities instead of trying to use a solution to stop the exploitation. This situation is a good example of one of the reasons why that is, as if a rule were written for the vulnerability that was already mentioned, it wouldn’t take care of the other issue. Or the yet more issues in the same file. Security providers will often promote solutions that don’t actually fix the issue, because it is cheaper for them, even if it is produces poor results for their customers.

Plugin Security Scorecard Grade for Patchstack

See issues causing the plugin to get less than A+ grade

Plugin Security Scorecard Grade for WPScan

See issues causing the plugin to get less than A+ grade