CVE-2026-104648 in weMail Plugin
Summary
by MITRE • 11/03/2026
The weMail WordPress plugin through 2.1.6 does not restrict a site-wide third-party email-service API key to administrators, exposing it in an admin screen that users with the Editor role can reach by default, which allows them to obtain a reusable credential usable without a WordPress session to impersonate other users and sever the site's email-service connection.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 11/03/2026
The vulnerability identified in weMail versions up to 2.1.6 represents a critical authorization flaw rooted in improper access control mechanisms within the plugin’s administrative interface. Specifically, the configuration screen for third-party email service API keys is accessible to users holding the Editor role by default. In standard WordPress architectures, the Administrator role possesses full capabilities over plugins and settings, while lower-privileged roles such as Editor are typically restricted from modifying core site configurations or sensitive security credentials. By exposing this specific setting to Editors, the plugin violates the principle of least privilege, allowing individuals with significantly less trust than administrators to interact with high-sensitivity data storage endpoints. This misconfiguration creates a direct pathway for unauthorized actors who have compromised an Editor account to access and extract critical authentication tokens that are intended solely for administrative management.
The technical nature of this flaw is classified as CWE-269, Improper Privilege Control, which describes situations where software performs privileged operations without ensuring the actor has sufficient privileges. Furthermore, because the API key obtained from this screen can be used to authenticate against external email service providers independently of a WordPress session, it aligns with aspects of CWE-798, Use of Hard-coded Credentials, in terms of its utility as a persistent credential that does not require active web application sessions for exploitation. The attacker leverages the exposed API key to interact directly with the third-party email provider’s Application Programming Interface. This bypasses WordPress authentication entirely, meaning that even if session cookies are rotated or invalidated, the stolen API key remains valid and functional within the external service ecosystem until manually revoked by an administrator.
The operational impact of this vulnerability is severe due to its potential for lateral movement and persistent access. Once an attacker obtains a reusable credential usable without a WordPress session, they can impersonate other users through the email service provider if that provider supports user-level API interactions or account management features. More critically, the ability to sever the site's connection with the email service disrupts business continuity by halting transactional emails such as password resets, order confirmations, and marketing campaigns. This denial of service effect can cause significant financial and reputational damage. Additionally, depending on the specific capabilities granted by the third-party provider’s API key, an attacker might be able to send malicious phishing emails using the organization's trusted domain, thereby facilitating further social engineering attacks against customers or partners who trust communications from that source.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The most urgent action is for site administrators to upgrade weMail to version 2.1.7 or later, where this authorization check has been corrected to restrict access to the API key configuration screen exclusively to users with Administrator privileges. For sites unable to update immediately due to compatibility concerns, manual intervention is required by revoking the compromised API keys in the third-party email service dashboard and generating new ones that are only accessible via properly secured administrative endpoints. Security teams should also audit user roles on affected WordPress installations to ensure no unauthorized individuals hold Editor or higher privileges who do not require such access. Implementing multi-factor authentication for all administrator accounts adds an additional layer of defense, reducing the likelihood of initial credential compromise that leads to this exploitation chain. Regular security audits focusing on role-based access control configurations are essential to prevent similar misconfigurations in other plugins and core WordPress functionalities.