By default, WordPress allows administrator and editor users to inject JavaScript into pages, posts, comments and widgets. This is because administrator and editor users have the unfiltered_html capability.
Here at WPScan it is quite common to receive vulnerability reports via our submission form where the security researcher was not aware that administrator and editor users are allowed to inject JavaScript.
But does this mean that all vulnerabilities that only affect admin users are not valid? No.
Say a security researcher discovers an XSS vulnerability that only affects administrator users. As we already stated, administrator users are allowed to inject JavaScript anyway, so what’s the risk?
Some WordPress websites may purposely turn off the ability for administrator and editor users to inject JavaScript, to increase the site’s security. This can be easily done by setting the DISALLOW_UNFILTERED_HTML constant to true in the site’s wp-config.php file. Let’s say that website is highly sensitive and requires the top most security, The White House for example. If the XSS vulnerability is still exploitable, even though the website has explicitly turned off the unfiltered_html capability, then we would definitely consider that a valid vulnerability. One administrator user could inject malicious JavaScript into another administrator user’s web browser.
Another reason why admin XSS vulnerabilities are still valid is because of the WordPress multisite feature. When the multisite feature is enabled, administrator users lose the unfiltered_html capability and it is given to Super Admin users. In this case, WordPress no longer allows administrator users to inject JavaScript. And if a way is found to bypass that, then it is a valid vulnerability.
The risk of Cross-Site Scripting (XSS) vulnerabilities affecting WordPress administrator users is low. In most cases administrator users are allowed to inject JavaScript anyway. To exploit XSS vulnerabilities, user interaction is usually needed, such as a logged in administrator user clicking on a malicious link. And there may also be Cross-Site Request Forgery (CSRF) nonces involved.
But just because a vulnerability is unlikely to be exploited, or is difficult to exploit, does not mean that we should ignore it. WordPress powers so much of the web it’s hard to keep up with the latest market share percentages. There must be thousands of different types of configurations and implementations, and we can not assume, just because a vulnerability is of low risk, that it won’t affect one of those sites in a more serious way.
Here are a couple of examples of administrator XSS vulnerabilities from our WordPress vulnerability database:
