On April 6, the WordPress plugin XML Sitemaps (Google XML Sitemaps) was closed on WordPress’ plugin directory. The only information given was this vague message:

This plugin has been closed as of April 6, 2022 and is not available for download. This closure is temporary, pending a full review.

At the time. the plugin was listed as having 2+ million active installations.

On April 8, the developer submitted a new version of the plugin to the directory where one of the changelog entries was:

Fixed security issue related to Cross-Site Scripting attacks on debug page

As at least one of our customers was using the plugin, we reviewed that and assessed that there wasn’t really a vulnerability that we should warn our customers about that.

If any of our customers had asked us about the situation, we could have explained what the situation with the plugin was. Unfortunately, not everyone has access to that type of resource or takes advantage of that. Making that more of a problem is that others having been spreading misinformation about that situation.

On the support forum for the plugin on the WordPress website, there was a discussion going on about the closure, which was closed by a moderator with this odd statement:

A sitemap is a sitemap; it doesn’t matter which plugin generates it.

As this topic is going nowhere, I’m going to close it.

A second topic was started because the first one was closed and the first reply, which was made 18 days ago, made this striking claim:

You should remove this ASAP… I am quite sure it has been the source of a backdoor hack to several of my sites.
Wordfence reports it as a critical issue.

There was no evidence provided that the plugin had anything to do with their websites being hacked, and considering the plugin is widely used, it wouldn’t be surprising that a website using it was hacked.

There was a follow up reply with someone else that had a website that had been hacked recently, but again no evidence was provided this was caused by the plugin:

Oh no. Thank you for this heads up, I had not heard about it but yes, my site has been recently hacked.

On May 26 the plugin was re-opened on the WordPress plugin directory. The plugin has lost installs since closed and is now down to 1+ million active installations.

It appears that on May 30 the claim of a security issue that the led to closure was finally disclosed:

The plugin does not sanitise and escape a settings before outputting it in the Debug page, which could allow high privilege users to perform Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup)

That information came from Automattic’s WPScan, which as is usual, hasn’t done basic due diligence with the claim. It states that “high privilege users” could have done something, but who exactly would that be? That isn’t hard to check on and the answer is users with the Administrator role:

209

add_options_page(__('XML-Sitemap Generator', 'sitemap'), __('XML-Sitemap', 'sitemap'), 'administrator', self::GetBaseName(), array(__CLASS__, 'CallHtmlShowOptionsPage'));

So the attacker has to be logged in as an Administrator. Even then, all the attacker is able to do is place JavaScript code on the plugin’s Debug page.

Here, again, is the original hacking claim:

I am quite sure it has been the source of a backdoor hack to several of my sites.

Not only would the “vulnerability” not allow the attacker to directly upload a backdoor, but the attacker would already be an Administrator, which would already normally allow them to upload a backdoor.

Unfortunately, the second topic was also closed (no reason was given for that), so no one can point out the plugin was unconnected to the hackings.

This false vulnerability report was given a CVE id by WPScan, CVE-2022-1896, despite not really being a vulnerability.

Takeaways

One key takeaway from this is that the risk of security vulnerabilities in WordPress plugins varies widely and in recent times often there really isn’t a vulnerability despite claims coming from supposedly reputable companies, like Automattic. That is an area where our service can help a lot, as we are always available to help customers to understand the implications of a vulnerability that was or is currently in a plugin they use. Other providers, like WPScan, don’t provide that, while providing misinformation to their customers.

Another key takeaway from this is the importance of doing the actual work to determine how websites are being hacked. You don’t determine that by looking at misleading information like Wordfence’s claim of a “critical” issue here or by assuming that if a plugin you have used contained a security issue, it was the source. A big problem with not doing the work to determine the source is that may still exist on your website, leaving your website open to being hacked again. Depending on what it is and if it is otherwise known about, it may leave other websites open to being hacked as well. That second part might explain why so many security companies don’t do the work to determine how websites are hacked, since finding and fixing issue means less potential business for them.

Plugin Security Scorecard Grade for WPScan

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

Plugin Security Scorecard Grade for XML Sitemaps

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