CVE-2026-93889 in Mail Logging & Catcher Plugin
Summary
by MITRE • 10/03/2026
The Mail logging – WP Mail Catcher plugin for WordPress is vulnerable to Stored Cross-Site Scripting via PHPMailer 'wp_mail_failed' Error Message in all versions up to, and including, 2.1.12 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. Successful exploitation requires a separately installed plugin, such as Contact Form 7, that passes unauthenticated user-controlled input into mail fields whose content PHPMailer will include in its failure error message.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/03/2026
The vulnerability identified in the WP Mail Catcher plugin for WordPress represents a significant security risk due to insufficient input sanitization and output escaping mechanisms within versions up to 2.1.12. This flaw allows unauthenticated attackers to execute Stored Cross-Site Scripting attacks by injecting arbitrary web scripts into pages that are subsequently accessed by users. The core of the issue lies in how PHPMailer handles error messages during mail transmission failures, specifically through the wp_mail_failed action hook. When a mail operation fails, the plugin includes details from the failure message directly in its output without adequately sanitizing or escaping potentially malicious content embedded within those fields.
Exploitation of this vulnerability relies on a specific operational context involving other plugins that facilitate unauthenticated user input into email-related fields. For instance, when combined with widely used contact form plugins such as Contact Form 7, attackers can submit crafted data through public-facing forms. This untrusted input is then passed into mail fields which PHPMailer processes during an attempted send operation. If the transmission fails for any reason, the plugin captures the error message generated by PHPMailer and displays it to the user. Because the original malicious payload remains embedded in this error output without proper encoding, it executes within the victim's browser session whenever they view the affected page or notification.
The impact of this vulnerability extends beyond simple script execution, potentially leading to account takeover, session hijacking, defacement, or malware distribution depending on the context and capabilities of the injected scripts. Since the attack does not require authentication, any visitor to a vulnerable site can be targeted if they interact with the compromised form or view pages displaying the tainted error messages. This broadens the attack surface significantly compared to authenticated-only vulnerabilities, making it easier for threat actors to propagate malicious code across multiple user sessions and devices.
From an industry standards perspective, this vulnerability aligns with CWE-79, which classifies improper neutralization of input during web page generation as a common cause of cross-site scripting flaws. The attack vector also corresponds to MITRE ATT&CK techniques related to client-side injection, where adversaries leverage trusted applications or websites to deliver malicious payloads that execute in the context of legitimate users. Understanding these mappings helps security teams prioritize remediation efforts and align their mitigation strategies with established best practices for web application security.
To mitigate this risk, administrators should immediately update WP Mail Catcher to a version newer than 2.1.12 where input sanitization and output escaping have been properly implemented. Developers must ensure that all data originating from untrusted sources is rigorously validated before processing and securely encoded prior to rendering in HTML contexts. Utilizing WordPress built-in functions such as esc_html or wp_kses_post can help prevent the execution of injected scripts by neutralizing special characters. Additionally, implementing Content Security Policy headers can provide an additional layer of defense by restricting the sources from which scripts are allowed to load, thereby reducing the impact even if a vulnerability is present. Regular security audits and penetration testing should be conducted to identify similar flaws in other plugins that interact with mail services or display dynamic content derived from user input.