CVE-2026-121730 in emailflare
Summary
by MITRE • 11/04/2026
emailflare before commit cf31f33 contains a missing authorization vulnerability in POST /api/inbox/compose that allows authenticated members to send mail as any sender address. Attackers can supply an arbitrary from field, which is passed unchecked to the Cloudflare send call, to impersonate other users or the organization to external recipients.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/04/2026
The emailflare application, prior to commit cf31f33, suffers from a critical missing authorization vulnerability within its API endpoint POST /api/inbox/compose. This flaw stems from an insufficient validation of input parameters related to the sender identity during the mail composition process. Specifically, while the system correctly authenticates users and ensures they have valid credentials to access the application, it fails to enforce proper authorization checks regarding which email addresses are permitted as senders for a given authenticated session. The architectural design assumes that only legitimate user accounts should be able to initiate outbound communications, but the implementation lacks a mechanism to verify that the from address provided in the request payload corresponds to an account owned or authorized by the currently logged-in user.
Technically, this vulnerability manifests when an attacker constructs a malicious HTTP POST request targeting the compose endpoint and includes an arbitrary email address in the from field of the message headers. The backend application processes this input directly without performing any cross-reference against the authenticated user's profile data or domain restrictions. Consequently, the unchecked sender address is passed verbatim to the underlying Cloudflare Send service integration. This lack of server-side validation allows for complete control over the envelope sender and header from fields, effectively bypassing standard anti-spoofing controls that rely on application-level identity verification rather than just transport-layer authentication.
The operational impact of this vulnerability is severe, primarily facilitating email spoofing and impersonation attacks. An authenticated attacker can exploit this flaw to send emails that appear to originate from any external domain or specific internal user accounts. This capability enables sophisticated social engineering campaigns where the victim receives messages seemingly sent by trusted entities such as executives, IT support staff, or well-known brands. The ability to bypass sender verification significantly lowers the barrier for phishing attacks, business email compromise schemes, and reputation-based spam operations. Furthermore, because the emails are delivered through a legitimate cloud provider infrastructure like Cloudflare Send, they may exhibit higher deliverability rates and lower likelihood of being flagged by recipient spam filters compared to messages sent from known malicious IP addresses or unverified domains.
From a classification perspective, this issue aligns with CWE-269 Improper Privilege Escalation, as the attacker leverages valid credentials to perform actions beyond their authorized scope regarding sender identity. It also relates closely to CWE-748 Improper Declaration of Vulnerability Protected Context and CWE-345 Insufficient Verification of Data Authenticity within the context of message headers. In terms of offensive security frameworks, this vulnerability supports techniques found in MITRE ATT&CK T1566 Phishing, specifically sub-techniques involving spoofing email sender addresses to increase trustworthiness among targets. The exploitation path is straightforward and does not require complex chain attacks, making it a high-risk finding for any organization relying on this service for critical communications.
Mitigation strategies must focus on implementing strict server-side validation of the from field before forwarding requests to external mail services. Developers should enforce that the sender address matches one of the verified identities associated with the authenticated user account or belongs to an explicitly whitelisted domain if multi-tenant functionality is required. Additionally, integrating SPF and DKIM checks at the application level can help ensure compliance with email authentication standards even when internal controls are bypassed. For organizations using versions prior to commit cf31f33, immediate patching is essential. In cases where upgrading is not immediately feasible, implementing a reverse proxy rule or WAF policy that restricts allowed sender patterns based on user session data can provide temporary relief until the codebase is updated with proper authorization logic.