Reflected XSS in WordPress Plugin Admin Pages

The administrative dashboard in WordPress is a pretty safe place: Only elevated users can access it. Exploiting a plugin’s admin panel would serve very little purpose here — an administrator already has the required permissions to do all of the actions a vulnerability could cause.

While this is usually true, there are a number of techniques bad actors are using to trick an administrator into performing actions they would not expect, such as Cross Site Request Forgery (CSRF) or Clickjacking attacks. By using these techniques, an attacker can exploit a vulnerability on the behalf of an administrator — potentially making a minor issue a major security problem.

An attacker can exploit these vulnerabilities by having an administrator visit a link — or even view an image — by using a specifically crafted payload specific to the targeted website.

In this post, we’ll demonstrate many vulnerabilities we’ve found having a similar source, all of which lead to a reflected XSS in administrative pages.

Here is a list of plugins which were vulnerable to this attack:

• Absolutely Glamorous Custom Admin < 6.5.5
• All In One WP Security & Firewall < 4.4.4
  • This one only works when an administrator has an older browser. New browsers aren’t vulnerable to this technique.
• Asset CleanUp: Page Speed Booster < 1.3.6.7
• Cookiebot < 3.6.1
• Elementor Addon Elements < 1.6.4
• LearnPress < 3.2.7.3
• Sticky Menu, Sticky Header (or anything!) on Scroll < 2.21

The Vulnerabilities

Sensitive actions on a website need to be protected using a wide variety of techniques: permission checks, nonces, secrets, and more. Places commonly overlooked in terms of security are pages which do not trigger actions, such as plugin settings or overview pages.

What we discovered is that all of these plugins had a variety of the same problem: They trust the browser URL to contain only valid information, while not using other mechanisms to sanitize or validate the data it contains. As the data was not properly sanitized, it always led to a reflected XSS vulnerability where malicious code could be executed on the behalf of the user.

Since there are multiple variants of the vulnerability on each of these plugins, let’s see the typical scenario: The vulnerable settings page.

Settings pages frequently have multiple tabs which split the information by category. To distinguish which of these tabs is currently being used, these plugins often use the tab request argument to conditionally render different sections of the page.

Here is a vulnerable sample:

In this scenario, by using $activeTab as a value, class, or by rendering it anywhere without sanitizing it, we get a reflected XSS using the tab argument.

Finally, to exploit this XSS, all we need to do is send an administrator a link to the settings page with our payload in the tab argument:

http://website.invalid.com/wp-admin/options-general.php?page=plugin-settings&tab="><script>alert(document.domain)</script>

Since the link is for the same website, an unsuspecting administrator might be tempted to click on it — an action which would trigger the exploit on his own account.

Conclusion

While certain vulnerabilities are definitely more dangerous than others, all vulnerabilities regardless of their severity can be used by attackers to damage your website.

To mitigate risk and prevent an exploit, it’s imperative that you keep all website software and third-party components up to date with the latest security patches. We also encourage website owners to take advantage of file integrity monitoring services that can help you identify indicators of compromise.

If you’re having difficulty staying on top of updates, you can use a web application firewall to virtually patch known vulnerabilities until you can get to them yourself.