When it comes to the very common occurrence of vulnerabilities in WordPress plugins failing to really be fixed, many providers are often involved in that failure. That is the case with a recently disclosed vulnerability in the 100,000+ install plugin Genesis Blocks.

That plugin comes from WP Engine, which markets itself as having a dedicated security team, though, one that keeps “your website vulnerabilities up to date” instead of fixing them:

They also market that they provide “plugin vulnerability notifications to keep your site secure”, which isn’t useful if the data isn’t accurate, as we will see is the case with the undisclosed provider of their data.

CVE, WPScan, and CleanTalk

The CVE system recently claimed that a persistent cross-site scripting (XSS) vulnerability had been fixed in the plugin:

The Genesis Blocks WordPress plugin before 3.1.3 does not properly escape data input provided to some of its blocks, allowing using with at least contributor privileges to conduct Stored XSS attacks.

The only source provided to back that claim up was from the party that CVE allowed to make that claim in the first place, WPScan, which is owned by Automattic. Why isn’t there a second source confirming that, especially when WPScan is well known to not vet their own information? Despite that lack of vetting, WPScan claims that WP Engine relies on their data.

The only additional information provided is a proof of concept. The details of the vulnerability and how it was fixed are not provided.

WPScan in turn points to another provider, CleanTalk, which also has a track record of inaccurate information, as their source. The information they provided reads like it was written by someone who had no idea what they are talking about.

CVE (Again), Wordfence, and Patchstack

Separately, the CVE system made this claim about the plugin:

The Genesis Blocks plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the block content in all versions up to, and including, 3.1.2 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with contributor access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

According to CVE, “There is one CVE Record for each vulnerability in the catalog.” Despite that, there are two records for the same vulnerability.

That listing isn’t clear if the vulnerability was supposed to have been fixed. But the cited source, Wordfence, claimed it was. Like WPScan, Wordfence is known for not vetting their information.

Another provider, Patchstack, is citing the same CVE information and claiming this was fixed:

Curiously, they claimed to have published this, despite copying information from other providers:

They also claim to have provided an early warning, despite copying the information that was already public before April 2.

Unfixed Vulnerability

Prior to that information being released, WP Engine released a new version with the changelog reading “Fixed: Minor security vulnerability.” Looking at the changes made, what we noticed was that only one block had a security change being made. Going back to the first claim made by CVE, it said that the plugin did not “properly escape data input provided to some of its blocks.” Either there was only a problem with one block or there still is a vulnerability. A quick check of the code confirmed it was the latter, and the plugin is still as vulnerable as it was before it was “fixed.”

We confirmed that there is still at least an issue involving the function genesis_blocks_render_sharing() in the file /src/blocks/block-sharing/index.php. There may be more instances.

In that function, user input from the variable $attributes is not escaped before it is later output:

268
269
270
271
272
273
274
275
276
277
278
279
280

$block_content = sprintf(
	'<div class="wp-block-genesis-blocks-gb-sharing gb-block-sharing %2$s %3$s %4$s %5$s %6$s">
		<ul class="gb-share-list">%1$s</ul>
	</div>',
	$share_url,
	isset( $attributes['shareButtonStyle'] ) ? $attributes['shareButtonStyle'] : null,
	isset( $attributes['shareButtonShape'] ) ? $attributes['shareButtonShape'] : null,
	isset( $attributes['shareButtonSize'] ) ? $attributes['shareButtonSize'] : null,
	isset( $attributes['shareButtonColor'] ) ? $attributes['shareButtonColor'] : null,
	isset( $attributes['shareAlignment'] ) ? 'gb-align-' . $attributes['shareAlignment'] : null
);
 
return $block_content;

The exploit-ability of that is confirmed with the proof of concept below.

We tried to reach out to WP Engine about this, but they don’t provide any way to directly contact them about security issues unless you are a customers, which is odd. (For whatever reason, they do link to a strange a bug bounty program at a third-party,  which doesn’t offer any bounties, which is also odd.)

Proof of Concept

Creating a new post as a user with the Author role, which doesn’t have the unfiltered_html capability, with the following added to the block editor’s code editor, will cause an alert box with any available cookies to be shown when hovering over the plugin’s content on the page.

<!-- wp:genesis-blocks/gb-sharing {"clientId":"1","shareButtonStyle":"\u0022 onmouseover=\u0022alert(document.cookie);\u0022 class=\u0022"} /-->

Plugin Security Scorecard Grade for Genesis Blocks

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

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