Part of how we keep track of vulnerabilities in WordPress plugins is by monitoring the WordPress support forum for relevant topics. What we are seeing a lot these days are developers who are trying to deal with rather unclear claims of vulnerabilities in their plugins. Two weeks ago, we helped a developer to get an issue in their plugin addressed after another provider, Patchstack, as usual, was rather unhelpful. There are lessons for plugin developers and Patchstack. We don’t have much hope for Patchstack addressing the issues, since they are already long running and well known, but developers have a chance to pretty easily improve their handling of the security of their plugins.

Patchstack inaccurately claimed that the plugin Simple SEO contained a cross-site request forgery (CSRF) vulnerability. While that was part of the issue, the vulnerability was more serious than that, though not a serious vulnerability. Here is the information they provided on that:

Mika discovered and reported this Cross Site Request Forgery (CSRF) vulnerability in WordPress Simple SEO Plugin. This could allow a malicious actor to force higher privileged users to execute unwanted actions under their current authentication.

The developer of the plugin reasonably responded to someone bringing that to their attention this way:

Can you provide specifics? File, reference line #, etc? The link above just reintegrates what you have stated.

That gets to a fundamental problem with Patchstack. They don’t provide the needed information for others to check on their claims. We have repeatedly found that their information is inaccurate when we check in to their claims. Other providers don’t do the needed work to provide accurate information and simply copy their inaccurate information. (In the case of Wordfence, while claiming their data is “impeccable”.)

The developer then stated they had done multiple audits and not found the claimed vulnerability:

I have had several audits of the plugin code and there is no CSRF vulnerability found. Can you please send me specific details from your host to let me know where their concern is? What line in the code, what file. What vulnerabilities they have found and their recommendations on fixing it. Thanks!

Based on other comments and changes they made, it appears the developer was confused and was looking for a cross-site scripting (XSS) vulnerability instead of a CSRF vulnerability. It seems like an easy enough mistake to make for someone without security expertise, but someone like that shouldn’t be trying to audit the code for security issues.

Based on what we know about Patchstack, we could easily make a guess as to what was likely the relevant issue. On the plugin’s admin page, there were several buttons that linked to URLs that didn’t contain a nonce, which is part of preventing CSRF. Looking at the underlying code to confirm that, we found that Patchstack had not really checked over things. If they had provided the information needed by others to confirm the issue, they would have seen what they missed.

Patchstack Missed a More Significant Issue

One of the buttons is labeled Create Sitemap. When clicking on it, a request is sent to /wp-admin/admin-post.php?action=sseo_create_sitemap. The underlying code that connects that to a function in the plugin is as follows:

51

add_action('admin_post_sseo_create_sitemap', [$this, 'generateSiteMap']);

That makes the function accessible to anyone logged in to WordPress, while the button is only accessible to Administrators. So the code that then runs should do a capabilities to limit access, but it didn’t:

131
132
133
134

public function generateSiteMap() {
	if (get_option('sseo_generate_sitemap') == true) {
		$sitemap = new Sitemap();
		$sitemap->buildSitemap();

There is also a lack of a nonce check, which makes sense based on the URL not containing a nonce.

After reviewing that, we contacted the developer. We let them know what appeared to be at issue, linked to the relevant WordPress documentation to address it, and offered to help them with that.

They made an attempt to fix this, by adding the missing nonces to URLs connected to the buttons. They didn’t run the change by us first, so we couldn’t explain to them that this didn’t solve the issue. As they still needed to check for a valid nonce as well. They also needed to add the capabilities check.

We then notified them of the remaining issues. They then asked us if the changes they were planning to make would address this. It still needed a bit of work. They quickly improved the code and released a new version that addressed Patchstack’s claim.

The changed code for the function show above is this:

140
141
142
143
144
145
146
147

public function generateSiteMap() {
	$nonce = null;
	if (!empty($_REQUEST['_wpnonce'])) {
		$nonce = $_REQUEST['_wpnonce'];
	}
 
	if (wp_verify_nonce($nonce) && current_user_can('administrator')) {
		if (get_option('sseo_generate_sitemap') == true) {

The function wp_verify_nonce() checks for a valid nonce to prevent CSRF and the function current_user_can() does the needed capabilities check.

Better Handling by Developers

One big takeaway for developers is to be willing to ask for help. We have for years offered to help developers fix vulnerabilities in their plugins for free. Even when they know about that, because we have, say, contacted them because they failed when attempting to fix a vulnerability, they rarely take advantage of that. If someone is offering to help, take advantage of it.

Another takeaway for developers is that they should get a security review of their plugin done if possible. If they are not knowledgeable about security, having a thorough professional review done can make sure the plugin is secured. So you don’t end up in the situation this developer was in where they had Patchstack creating a headache. It doesn’t have to cost much. For this plugin, our price to do a review would be $100. Based on the poor security record of plugins from major plugin developers, many developers who could easily afford reviews are not having them done.

Better Handling by Patchstack

Providing clear information on claimed vulnerabilities is important for multiple reasons. One being that without it is hard for developers to address a problem, as can be seen here. Another is that we often find that there are wider security issues when we looked into a claimed vulnerability. By providing clear information, it is easy to spot that, even if, as is often the case, a provider like Patchstack misses it. Patchstack isn’t doing that. They should.

Making that situation more problematic, Patchstack has taken actions to get others to report vulnerabilities to them instead of developers or more responsible parties. WordPress is the best alternative if the developer can’t be reached. WordPress should and could take action to stop that diversion, but so far they haven’t done much on that front.

Plugin Security Scorecard Grade for Patchstack

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