In early January 2024, a new vulnerability was disclosed that affects the widely-used Persian Fonts WordPress plugin (up to version 1.6). Tracked as CVE-2023-7167, this flaw is a Stored Cross-Site Scripting (XSS) vulnerability that could allow attackers to inject malicious scripts — even in scenarios where admins don’t have unrestricted HTML rights, such as on WordPress Multisite installations.
This post explains CVE-2023-7167 in simple terms, shows exactly how it can be exploited, and provides tips for staying safe.
What is CVE-2023-7167?
CVE-2023-7167 is a security issue found in the Persian Fonts WordPress plugin (versions through 1.6). The core problem is that the plugin does not properly sanitize and escape some of its settings fields. As a result, users with high privileges (like admins or site managers) can inject and store malicious JavaScript code — code that runs whenever someone visits certain admin pages.
Even worse, this attack is possible even if the user’s unfiltered_html capability is disabled, which is often the case in multisite WordPress installations to restrict risky code. This means multisite owners and their network admins are especially at risk.
Was This Vulnerability Exploited?
As of publication, there are no public reports of active exploitation, but proof-of-concept code is easy to write and the plugin is popular in the Persian WordPress community. Attackers could use this bug for:
Why Does This Happen?
The Persian Fonts plugin lets privileged users configure font settings using a custom admin interface. The plugin saves some configuration options directly into the WordPress database, but fails to sanitize user input — that is, it doesn’t remove or escape potentially dangerous HTML or JavaScript.
If an attacker (with admin-level access, or a compromised admin account) enters malicious input in the relevant settings, the script will be stored and executed whenever pages that display that setting are loaded in the dashboard.
Example Vulnerable Code (Based on Decompilation)
Below is a simplified sample of *how* the plugin might be saving and displaying settings, missing any sanitization:
// Storing the setting (vulnerable)
if (isset($_POST['persian_fonts_custom_css'])) {
update_option('persian_fonts_custom_css', $_POST['persian_fonts_custom_css']); // NO sanitization!
}
// Displaying the setting (vulnerable)
echo get_option('persian_fonts_custom_css');
If a malicious user submits
<script>alert('XSS')</script>
The code will be stored as-is in the database and rendered directly on relevant admin pages – immediately executing the JavaScript.
Proof-of-Concept Exploit
### Step-by-Step Exploit (For Testing/Education Only!)
> Note: Only test this on a site you own or have *explicit permission* to use for security research.
`html
Reload the page (or any admin page where the setting is displayed).
You should see an alert box — proof the XSS has fired!
Original Advisory and Reference Links
- NVD – CVE-2023-7167
- Patchstack Advisory: Persian Fonts < 1.7 - Authenticated Stored XSS
- WPScan Entry
## How To Fix / Patch
The plugin was reportedly patched in version 1.7.
If you’re developing plugins, always use built-in WordPress sanitation functions
update_option('persian_fonts_custom_css', wp_kses_post($_POST['persian_fonts_custom_css']));
and
echo esc_html(get_option('persian_fonts_custom_css'));
For more info:
- WordPress Data Sanitization and Validation
Conclusion
CVE-2023-7167 is a strong reminder that even settings pages used only by admins can be dangerous if you don’t sanitize and escape user input — especially in WordPress Multisite, where the unfiltered_html capability is intentionally limited.
If you use the Persian Fonts plugin, update now. If you manage WordPress sites, always be careful with plugins that process or display custom user input — and check for updates regularly.
Stay safe, update often, and always sanitize!
*Written exclusively for you. If you want more code analysis, reach out!*
Timeline
Published on: 02/27/2024 09:15:37 UTC
Last modified on: 08/28/2024 16:35:05 UTC