WordPress (and Open Source In General) Have a Big Problem With a Lack of Vulnerability Transparency

Looking back at some things while preparing a post about a WordPress security provider misleading people about the European Union’s Cyber Resilience Act, we ran across a letter that was put out by WordPress and several other open source CMS. In that they made this claim about fixing potential vulnerabilities in open source code:

Tens of thousands of developers are empowered to identify and fix potential vulnerabilities, because all FOSS code is made publicly available — unlike proprietary software code that is kept secret.

There are a couple of significant problems with that. One that won’t be the subject of this post, which is that, just because the code is publicly available, it doesn’t mean that developers can fix the code. They can fix the code in their own usage, but the maintainer of the software has to accept the fix for it to be generally fixed. The other is that open source software, and WordPress is particular, faces a problem with a lack of transparency with information on vulnerabilities. That makes it significantly harder to make sure that security issues are fully fixed. It also makes it much harder to understand the true risk of vulnerabilities or even if there really has been a vulnerability.

We will focus on one example where the largest submitter to the CVE system, who isn’t providing basic information on claimed vulnerabilities, failed correctly identify a vulnerability and failed to make sure it was fully fixed. But before we do that, we are going to look at the limited information that is provided for those trying to determine if a security third-party librariy actually affects software that includes it.

Does This Affect A WordPress Plugin

Recently, a WordPress plugin with 300,000+ installs was run through our Plugin Security Scorecard. That identified that it was using an outdated version of a third-party library that contained a security issue. Here is the relevant entry on the GitHub project for that:

The impact section reads:

Improper header parsing. An attacker could sneak in a newline (\n) into both the header names and values. While the specification states that \r\n\r\n is used to terminate the header list, many servers in the wild will also accept \n\n.

So is that a vulnerability or a lesser security issue? It reads to us as a security issue, but other information on the page suggests it is a vulnerability.

For someone familiar with security, but not with that library, it doesn’t provide much to go on to try to figure out the impact on the software using that library.

That plugin it turned out also contains another an outdated version of a third-party library that contained security issues. For one of those issues, the developer provides even less information to work on:

The description reads:

It has been discovered that malicious HTML using special nesting techniques can bypass the depth checking added to DOMPurify in recent releases. It was also possible to use Prototype Pollution to weaken the
depth check.

This renders dompurify unable to avoid XSS attack.

It doesn’t provide an example of what the malicious HTML would be to check if the issue was properly resolved in the library. You also don’t have something to use to check if the plugin’s usage of the library is impacted by that.

Patchstack Hides Information That Would Show They Missed Unfixed Security Issue

Inside the WordPress ecosystem, things are not better. Sticking with FluentSMTP, a week ago Patchstack added an entry for a claimed vulnerability in the plugin. Here is the page for that:

It’s bereft of even basic information. Other than a type of vulnerability and a version they claimed it was fixed in. So no one can directly tell what the risk of this really is or if it was fixed. Looking at the changelog for the version this was supposed to be fixed in, adding more detail as it reads “Security: Nonce Verification fixed for slack REQUEST (props to patchstack).” That is information that the developer provided in October. Why is Patchstack providing less information than they developer and providing months later?

Taking a look at the changes made in that version of the plugin, we could identify the relevant code. Here is that code where the nonce check was added, which is located in the file /app/Hooks/Handlers/AdminMenuHandler.php :

if (isset($_REQUEST['sub_action']) && $_REQUEST['sub_action'] == 'slack_success') {
	add_action('admin_init', function () {
		$nonce = Arr::get($_REQUEST, '_slacK_nonce');
		if (!wp_verify_nonce($nonce, 'fluent_smtp_slack_register_site')) {
			wp_redirect(admin_url('options-general.php?page=fluent-mail&slack_security_failed=1#/notification-settings'));
			die();
		}
 
		$settings = (new Settings())->notificationSettings();
		$token = Arr::get($_REQUEST, 'site_token');
 
		if ($token && $token == Arr::get($settings, 'slack.token')) {
			$settings['slack'] = [
				'status'      => 'yes',
				'token'       => sanitize_text_field($token),
				'slack_team'  => sanitize_text_field(Arr::get($_REQUEST, 'slack_team')),
				'webhook_url' => sanitize_url(Arr::get($_REQUEST, 'slack_webhook'))
			];
			$settings['active_channel'] = 'slack';
			update_option('_fluent_smtp_notify_settings', $settings);

What you have there is code that runs during admin_init, which means it is accessible to even those not logged in to WordPress. Patchstack’s vague claim about the supposed vulnerability was that it could “allow a malicious actor to force higher privileged users to execute unwanted actions under their current authentication.” That isn’t right. A malicious actor can access the action themselves as there isn’t a restriction on who can access the code. The only thing stopping them now is the nonce check that was added. So this was actually what we classify as a privilege escalation vulnerably, which is a more serious because an attacker doesn’t have to involve someone else in exploitation.

Patchstack is not only inaccurately describing the issue, but the issue still hasn’t been properly fixed. If Patchstack had provided the appropriate information here, someone could have easily caught that. Instead, the plugin has remained in an unnecessarily insecure state since October. (We will let the developer know about that if they ever get back to us about .)

The problem is that Patchstack’s misinformation doesn’t stay with them. The CVE system allowed them to enter their false information into that:

If you complain to CVE about them allowing entries from parties known to not care about the accuracy of their information (like Patchstack), CVE’s response is to tell you to take it up with the party doing that. Which won’t resolve it.

It also got entered into Wordfence’s information: