CVE-2022-0218

What it actually does

CVE-2022-0218 is a missing authorization/capability-check flaw in the WP HTML Mail / codemiq WordPress Email Template Designer plugin. In versions up to and including 3.0.9, the REST API endpoint used for theme settings can be accessed by unauthenticated users. An attacker can read and modify template/theme configuration and inject attacker-controlled JavaScript into settings that are later rendered by the WordPress site or administrative interface, resulting in stored cross-site scripting with potential confidentiality and integrity impact.

Why it matters to the business

A vulnerable WordPress site can be modified by an unauthenticated internet attacker without needing a login. Successful exploitation can lead to website defacement, malicious redirects, credential/session theft from administrators or users who view affected pages, and loss of trust in outbound email branding or site content. The risk is elevated because exploitation is weaponized and the EPSS score is high, indicating meaningful likelihood of exploitation in the wild even though the issue is not currently listed in CISA KEV.

How an attack unfolds

An attacker first identifies a WordPress site using a vulnerable version of the WP HTML Mail / codemiq WordPress Email Template Designer plugin. They then send unauthenticated HTTP requests to the plugin’s REST API theme-settings endpoint. Because the endpoint does not properly verify user capabilities, the attacker can retrieve existing settings and submit modified settings that contain malicious JavaScript, such as script tags, event handlers, or external payload loaders. The payload is stored in the plugin configuration and later executes when an administrator, editor, user, or visitor loads an affected page or interface that renders those settings. From there, the attacker may steal cookies or nonces, perform actions in the victim’s browser, redirect users to phishing or malware pages, or further alter site content.

How to fix it

Upgrade the WP HTML Mail / codemiq WordPress Email Template Designer plugin to a version newer than 3.0.9 that includes proper authorization checks for the theme-settings REST API endpoint. If no fixed version is available through the normal plugin channel, disable and remove the plugin until a maintained release is available. As an interim mitigation, restrict access to WordPress REST API routes associated with the plugin using a web application firewall or reverse proxy rule, block unauthenticated requests to endpoints containing `themesettings`, and review/sanitize all saved plugin theme/template settings for injected JavaScript. Also rotate WordPress administrator sessions and credentials if exploitation is suspected.

How to confirm the fix worked

Confirm that no installed instance of the plugin is version 3.0.9 or earlier. From an unauthenticated session, attempt to access the plugin theme-settings REST API route and verify that it returns an authorization failure such as HTTP 401 or 403 rather than returning or accepting settings. Inspect saved WP HTML Mail theme/template settings for script tags, inline event handlers, encoded JavaScript, or unexpected external URLs. Validate that WAF or reverse proxy controls block unauthenticated requests to the vulnerable endpoint and that normal authenticated administrative functionality still works after upgrade or mitigation.

Typical attack path

1. Scan for WordPress sites exposing the WP HTML Mail / codemiq WordPress Email Template Designer plugin.
2. Confirm the plugin version is 3.0.9 or earlier, or test whether the theme-settings REST API endpoint is reachable without authentication.
3. Send an unauthenticated request to the theme settings endpoint to retrieve or inspect current configuration.
4. Submit modified theme settings containing malicious JavaScript or HTML event-handler payloads.
5. Wait for an administrator or user to load a page or interface where the stored template/theme settings are rendered.
6. Execute JavaScript in the victim’s browser to steal session material, perform unauthorized browser actions, redirect traffic, or stage additional compromise.

How to detect it

To determine whether exploitation already occurred, review HTTP access logs from the web server, CDN, WAF, and reverse proxy for unauthenticated requests to WordPress REST API paths containing `themesettings`, particularly write methods such as POST, PUT, or PATCH. Correlate suspicious requests with WordPress application logs and plugin setting changes around the same timestamps. Inspect the WordPress database or administrative configuration for WP HTML Mail theme/template settings containing `<script>`, JavaScript URI handlers, inline event handlers such as `onerror=` or `onclick=`, encoded payloads, unexpected iframes, or external domains not used by the organization. Check for follow-on indicators such as newly created administrator accounts, modified WordPress options, changed plugin/theme files, unexpected redirects, and anomalous admin activity shortly after a suspected XSS trigger. If logs are available, identify victim browsers that loaded the modified settings and review subsequent privileged actions performed from those sessions.

• /themesettings
• themesettings
• /wp-json/
• /wp-json/*themesettings*
• includes/class-template-designer.php
• <script
• </script>
• javascript:
• onerror=
• onload=
• onclick=
• eval(
• document.cookie
• localStorage
• sessionStorage
• atob(
• fromCharCode
• <iframe
• wp_html_mail
• wp-html-mail

What your security team should do

• Inventory WordPress sites for the WP HTML Mail / codemiq WordPress Email Template Designer plugin and prioritize any instance running version 3.0.9 or earlier.
• Upgrade immediately to a maintained fixed release newer than 3.0.9, or disable/remove the plugin where an update is not available.
• Review web server, WordPress, WAF, and CDN logs for unauthenticated requests containing `themesettings`, especially POST, PUT, or PATCH requests.
• Inspect plugin template/theme settings for injected JavaScript, unknown external domains, redirects, iframes, obfuscated payloads, and suspicious inline event handlers.
• Purge caches and CDN content after cleaning malicious settings so stored payloads are not served from cache.
• Reset administrator sessions, rotate credentials for privileged WordPress users, and review administrator activity if exploitation is suspected.
• Deploy WAF rules to block unauthenticated access to the vulnerable REST route and to alert on script injection attempts in plugin settings requests.
• Because exploitation is weaponized and EPSS is high, treat exposed vulnerable sites as urgent even though the vulnerability is not in CISA KEV.