As part of our cataloging the vulnerabilities in WordPress plugins for our service we come across false reports of vulnerabilities from time to time. So that others don’t spend their time looking over these as well, we post our findings on them.
If you are going to promote your “web application security scanner” as being “False positive free” as Netsparker does, it would probably be a good not to release advisories for vulnerabilities that don’t actually exist, using data from that tool. But that is what Netsparker did with several recent advisories for WordPress plugins, including a claim of a self XSS vulnerability in Yoast SEO.
When we ran across this one we were not even familiar with what a self XSS was. As defined by the Wikipedia it is a “a social engineering attack used to gain control of victims’ web accounts” that “operates by tricking users into copying and pasting malicious content into their browsers’ web developer console“. That doesn’t apply to a WordPress plugin vulnerability, so it seems that Netsparker was referring to cross-site scripting (XSS) done by the victim. That would be a social engineering attack, not a vulnerability, so calling the issue a vulnerability really doesn’t make much sense.
It gets more problematic in this case since when we went to look into where this vulnerability was supposed to be, we found the claimed vulnerability involves the plugin’s “Bulk editor” tool, which is only available to Administrator level users. Those users would normally have the unfiltered_html capability, which permits them to use the equivalent of cross-site scripting, so it isn’t a vulnerability for them to be able to do cross-site scripting. And if you can social engineer them to insert malicious code like this, you should be able to get them to do that in a post or page, so by the same token WordPress itself would be vulnerable, if this was a vulnerability. Beyond that, you always do the equivalent of this through the more common meaning of self XSS by the malicious content to the “web developer console”, so trying to claim this as a vulnerability is just odd.
Also, if you were trying to socially engineer a WordPress Administrator it seems like there would be much more effective things to try, like say getting them to installed a plugin with security vulnerability.
While this isn’t a vulnerability, it could be considered a bug. The Yoast SEO developers seem to be of the same mind on that, seeing as the changelog for the new version that is supposed to have fixed this vulnerability, they were refer to it as a “bugfix” and state: