CVE-2026-0691: WordPress CM E-Mail Blacklist XSS Flaw

CVE-2026-0691 Overview

The CM E-Mail Blacklist – Simple email filtering for safer registration plugin for WordPress contains a Stored Cross-Site Scripting (XSS) vulnerability in the black_email parameter. This vulnerability affects all versions up to and including 1.6.2 and stems from insufficient input sanitization and output escaping. Authenticated attackers with administrator-level access can inject arbitrary web scripts into pages that execute whenever a user accesses the affected page.

Critical Impact

Stored XSS allows persistent malicious script injection that executes in the context of other users' sessions, potentially leading to session hijacking, administrative account compromise, or further attacks on WordPress multi-site installations.

Affected Products

• CM E-Mail Blacklist – Simple email filtering for safer registration plugin for WordPress versions up to and including 1.6.2
• WordPress Multi-site installations using the affected plugin
• WordPress installations where unfiltered_html capability has been disabled

Discovery Timeline

• 2026-01-17 - CVE-2026-0691 published to NVD
• 2026-01-17 - Last updated in NVD database

Technical Details for CVE-2026-0691

Vulnerability Analysis

This Stored Cross-Site Scripting vulnerability exists in the WordPress plugin's backend settings interface. The vulnerability is classified under CWE-79 (Improper Neutralization of Input During Web Page Generation). The flaw occurs when processing the black_email parameter in the plugin's email blacklist settings functionality.

The attack requires network access and authenticated administrator-level privileges. While this increases the complexity of successful exploitation, the scope extends beyond the vulnerable component itself—injected scripts can affect other administrators or users who access the compromised pages. The impact includes potential unauthorized disclosure and modification of information, though availability is not affected.

This vulnerability specifically impacts WordPress multi-site installations and single-site installations where the unfiltered_html capability has been explicitly disabled, as these configurations would normally prevent administrators from inserting arbitrary HTML/JavaScript.

Root Cause

The root cause is insufficient input sanitization and output escaping in the plugin's settings handling code. When the black_email parameter is saved and subsequently rendered on the settings page, user-supplied input is not properly escaped, allowing HTML and JavaScript content to be stored and executed.

The vulnerable code resides in the plugin's settings view file at backend/views/settings/email_blacklist.phtml around line 67, where the blacklisted email values are output without proper sanitization. For technical details, refer to the WordPress Plugin Settings File.

Attack Vector

An attacker with administrator-level access to a vulnerable WordPress installation can exploit this vulnerability through the following approach:

1. Navigate to the CM E-Mail Blacklist plugin settings page
2. Insert malicious JavaScript code within the black_email parameter field
3. Save the settings, causing the malicious script to be stored in the database
4. When any user (including other administrators) accesses the settings page, the stored script executes in their browser context

The stored nature of this XSS means the payload persists and executes automatically for all users viewing the affected page, making it particularly dangerous for multi-administrator environments. The attack can be used for session hijacking, privilege escalation, or as a stepping stone for further attacks against the WordPress installation.

Detection Methods for CVE-2026-0691

Indicators of Compromise

• Unexpected JavaScript or HTML code present in the CM E-Mail Blacklist plugin settings
• Unusual entries in the black_email configuration field containing script tags or event handlers
• Browser console errors or unexpected script executions when viewing the plugin settings page
• Unauthorized changes to WordPress administrator accounts or settings

Detection Strategies

• Review the CM E-Mail Blacklist plugin settings for any suspicious entries containing JavaScript or HTML markup
• Implement Content Security Policy (CSP) headers to detect and block unauthorized inline script execution
• Monitor WordPress admin activity logs for unusual access patterns to plugin settings pages
• Use web application firewalls (WAF) with XSS detection rules to identify malicious payloads

Monitoring Recommendations

• Enable WordPress activity logging plugins to track all changes to plugin settings
• Configure alerts for modifications to the CM E-Mail Blacklist configuration
• Implement regular security audits of installed WordPress plugins and their configurations
• Monitor for browser-side anomalies using endpoint detection solutions

How to Mitigate CVE-2026-0691

Immediate Actions Required

• Update the CM E-Mail Blacklist plugin to the latest patched version immediately
• Review existing black_email entries for any suspicious or malicious content
• Audit administrator accounts for any unauthorized changes or suspicious activity
• Implement Web Application Firewall (WAF) rules to filter XSS payloads as a temporary measure

Patch Information

A security patch addressing this vulnerability is available through the WordPress plugin repository. The fix implements proper input sanitization and output escaping for the black_email parameter. Review the WordPress Plugin Changeset for technical details of the security fix.

Additional information about this vulnerability is available in the Wordfence Vulnerability Report.

Workarounds

• Temporarily disable the CM E-Mail Blacklist plugin until the patched version is installed
• Restrict access to the plugin settings page to only essential administrators
• Implement Content Security Policy headers to prevent inline script execution
• Enable the unfiltered_html capability restriction across all user roles if not already configured

# WordPress wp-config.php - Disable unfiltered HTML for all users
define('DISALLOW_UNFILTERED_HTML', true);

# Add Content Security Policy header via .htaccess
Header set Content-Security-Policy "script-src 'self'; object-src 'none';"