Recently there have been conversations popping up over a claim made by the WordPress security provider Wordfence that claims the Gutenberg plugin contains an authenticated persistent cross-site scripting (XSS) vulnerability. On Reddit there were a couple of recent conversations, where unsurprisingly, there wasn’t helpful information being provided. Things have been slightly better on the WordPress support forum for the plugin, but still you had alarmist information. One topic is titled, “Security breach and vulnerability in all versions.” Wordfence in turn, is citing Patchstack when making this claim. The reality is that there isn’t a vulnerability, something the WordPress security team told the original source of the claim, but which Wordfence and Patchstack have ignored.

While Wordfence and Patchstack are both claiming that this is an issue with the Gutenberg plugin, that isn’t what the original source they are citing says. Their post is titled
“CVE-2022-33994:- Stored XSS in WordPress” and they start it this way:

I found a Stored Cross Site Scripting vulnerability in WordPress that got rejected and got labeled as Informative by the WordPress Team.

There is only one mention of Gutenberg in their whole post. Despite that, Wordfence and Patchstack are claiming that the issue is in the Gutenberg plugin, but not WordPress. That doesn’t make sense, as if there really were an issue here, it would be in both.

Making things more confusing the original source of the claim says that the supposed issue doesn’t exist when using the classic editor in WordPress, only the block editor. Except that what they claim is at issue can also be done with the classic editor.

The Claimed Vulnerability

So what is the claimed vulnerability? What is claimed to be the vulnerability is having an HTML image tag that has as its source an SVG file. The original claimant uses this as an example:

<img src="https://malicious.domain/fox.svg" alt="" >

What is the risk of that? None. The argument from the claimant is that if someone opens the image, then JavaScript code could run:

the XSS payload will get executed once the SVG file is opened directly(which a lot of people normally do, including me)! An attacker can implant a BeEF XSS hook or deploy other similar techniques and takeover the entire browser of the victim and not just the WordPress domain! This attack could further devolve into Remote Code execution if the victim’s browser is not updated and is vulnerable

Which is also true with a simple link to another website. So there isn’t a vulnerability there or the web basically can’t exist, since you can’t even link to other websites.

Persistent (stored) cross-site scripting (XSS) involves an attacker being able to cause malicious JavaScript code to run on a website, which no party mentioned in this post claims is possible here.

What Would The Fix Be?

If you were to claim this was a vulnerability and ignore the whole link issue, the problem is that there is no way to detect SVG files that would be effective here. SVG files normally have a .svg extension, but you can set a web browser to serve up a SVG with any file extension or no file extension at all. If you checked if the URL was an SVG file when adding the image tag, that can always be changed. Even if you checked every time a page referencing it loads, the server could serve something different when the website checks the file.

CVE’s Role

If you read the original source’s post, they make clear that WordPress tried to explain this wasn’t a vulnerability. They ignored that and instead went to the CVE system and it got them to claim this was a vulnerability. By their own admission, the CVE system didn’t take much time to consider this, as they wrote they issued a CVE in less than 12 hours:

MITRE allocated it a CVE in less the 12 hours

They suggested that was because of the risk, but a simpler explanation is because there wasn’t due diligence done.

Recently the Python Software Foundation’s new security developer-in-residence claimed that CVE was doing the same with Python, as he said they “caused reports which weren’t security vulnerabilities to be accepted as CVEs”. There appears to be blackmail like situation where if you don’t participate in CVE they are okay with issuing false claims of vulnerabilities themselves or allow partners to do that. (Our own attempt to get them address inaccurate claims of vulnerabilities in WordPress plugins has gone nowhere as they claim rules have to be followed and then when they are they refuse to do anything when they are not followed by their own partners.)

Patchstack’s Strange Handling of This

Patchstack is currently claiming this is a vulnerability only in Gutenberg, but not WordPress, which doesn’t make sense. But it makes even less sense since one of their employees, Robert Rowley, claimed that it “poses no immediate risk to sites using Gutenberg to my knowledge” and said they wanted to “share ideas here for how we could defend against even a hypothetical attack” when creating a GitHub issue about this. They also acknowledge that simple links are also harmful if this is a real issue:

Visitors to the site could right-click the image, open it, and the javascript within the SVG will be ran under a different origin fom the website where Gutenberg was ran. (See: same-origin policy) This is very similar risk to following a malicious link.

Post Status Weighs In

The Post Status WordPress news site covered this in August of last year. It strangely claims this is both a vulnerability and a theoretical security concern:

There is no immediate risk of this vulnerability being exploited in the wild, so it represents a theoretical security concern that might help shape future development around SVGs in WordPress.

It can’t be both of those things.

The author also claimed that this is only in the Gutenberg plugin, despite the source of the claim saying the opposite:

what I believe is the first-ever reported vulnerability in Gutenberg (the plugin, not in WordPress core) to make the National Vulnerability Database.

It also praised the original claimant for their contribution to the WordPress project, despite WordPress having made clear this person was mistaken.

The author of that Post Status post is Dan Knauss, who now is involved with the Solid Security plugin, which probably helps to explain Solid Security’s own lack of understanding of security. Solid Security now relies on inaccurate data coming from Patchstack.

WordPress Should Be Warning About Unreliable Vulnerability Data Providers

As we have noted repeatedly in the past, both Wordfence and Patchstack are spreading inaccurate claims about vulnerabilities in WordPress plugins, often based on copying one another. In a worst case example, earlier this year an unfixed vulnerability was widely exploited in a WordPress plugin, three months after they both claimed the issue (described inaccurately) had been fixed, based on inaccurate information from yet another provider.

WordPress could and should be warning people about the unreliable nature of these data sources because it is having a decided negative impact on the WordPress community. That comes both in the form of inaccurate data, but also a lack of needed verification to ensure that real vulnerabilities have actually been fixed. The warning could come in the form of a public notice. It also could involve placing a warning label on the listings for plugins in the WordPress Plugin Directory that use these unreliable sources. An even stronger response could involve removing plugins using unreliable data sources, though simple warning about this seems like a good starting point.

Plugin Security Scorecard Grade for Gutenberg

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