Description

Froxlor through 2.3.10 does not enforce the mail.allow_external_domains policy in the EmailSender.add API command. When an administrator has enabled the allowed-sender feature but disabled external allowed-sender domains (mail.enable_allow_sender = 1, mail.allow_external_domains = 0), an authenticated customer with API access can still use EmailSender.add to register an arbitrary external sender address for their mailbox, which is stored despite the policy. This creates a bypass between the UI/administrator configuration and the API, and — where the generated mail configuration consumes the allowed-sender table — allows a customer to authorize sender identities outside their hosted domains, facilitating sender spoofing. Fixed in 2.3.12.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-09-26T14:16:57.917Z",
  "pubdate": "2026-09-26T14:16:57.917Z",
  "executiveSummary": "A security flaw exists in Froxlor through version 2.3.10 regarding the validation of the 'mail.allow_external_domains' policy within the EmailSender.add API command.\nThe vulnerability allows an authenticated customer with API access to bypass administrative security restrictions, enabling the registration of unauthorized external sender addresses even when explicitly forbidden by the configuration.\nThis represents a critical failure in policy enforcement between the administrative configuration layer and the API interface, resulting in potential sender identity spoofing.\nImpact includes the ability for authenticated users to misconfigure their mailbox identities in a manner that contradicts global security policies, potentially facilitating phishing or the distribution of illegitimate emails.\nThe vulnerability is resolved in Froxlor version 2.3.12. Successful exploitation requires an authenticated attacker to possess valid API credentials and target the affected EmailSender.add endpoint.",
  "technicalDetails": "The root cause of the vulnerability lies in an authorization check deficiency within the Froxlor API layer, specifically within the EmailSender.add function. While the web UI and global configuration files correctly respect the 'mail.enable_allow_sender = 1' and 'mail.allow_external_domains = 0' directives, the API handler fails to perform an equivalent validation check.\nWhen an administrator sets 'mail.allow_external_domains' to 0, the application logic is intended to prevent the association of email identities that do not belong to domains owned by the customer. However, the EmailSender.add API command does not consult the 'mail.allow_external_domains' state, allowing the input of arbitrary email addresses as sender identities.\nThe attack flow proceeds as follows: 1) The attacker obtains valid API credentials for a Froxlor customer account. 2) The attacker calls the 'EmailSender.add' API method, providing a payload containing an arbitrary external domain email address. 3) The API fails to validate this input against the 'mail.allow_external_domains' policy. 4) The application persists the unauthorized sender address into the database, which is subsequently consumed by the mail server configuration components.\nThe vulnerable component is the API interaction layer responsible for handling email identity management. By successfully registering these identities, the attacker can leverage the mail infrastructure to originate messages from unauthorized domains, effectively facilitating sender spoofing. The disparity between the UI-based validation and API-based input processing creates a 'policy bypass' scenario where the administrative intent is undermined by the lack of consistent policy enforcement across interface boundaries.\nThis vulnerability affects Froxlor versions up to and including 2.3.10. Exploitation requires authenticated access to the API, meaning the attack surface is limited to users already possessing API keys or administrative/customer session tokens, yet it allows those users to escalate their capability to spoof identities beyond the permitted boundaries established by the platform administrator."
}