CVE-2026-41232: 
PHP vulnerability analysis and mitigation

CVE-2026-41232 is an incorrect authorization vulnerability in Froxlor, an open-source server administration panel, that allows authenticated customers to add email sender aliases for domains belonging to other customers. The flaw exists in EmailSender::add() in all versions prior to 2.3.6, where a wrong array index causes domain ownership validation to be bypassed entirely. It was published on April 23, 2026, with a patch released in Froxlor 2.3.6. The vulnerability carries a CVSS v3.1 base score of 5.0 (Medium) (GitHub Advisory).

The root cause is classified as CWE-863 (Incorrect Authorization): in lib/Froxlor/Api/Commands/EmailSender.php at line 100, when processing a full email address (e.g., admin@domain-b.com) as an allowed sender, the code calls explode("@", $allowed_sender)[0], which yields the local part (admin) instead of the domain (domain-b.com). This local part is then passed to validateLocalDomainOwnership(), which queries the panel_domains table for a domain matching that string; since no domain named admin exists, the query returns false and the ownership check silently passes. The resulting mail_sender_aliases entry is then consumed by Postfix's sender_login_maps, which authorizes the attacker's mail account to send as the spoofed address. The wildcard (@domain) code path is not affected, as it correctly passes the domain portion (GitHub Advisory, Patch Commit).

Any authenticated customer on a multi-tenant Froxlor instance can impersonate email addresses on domains owned by other customers, bypassing Postfix's smtpd_sender_login_maps restriction. Because spoofed emails originate from the legitimate mail server, they may pass SPF and DKIM checks for the target domain if those records point to the Froxlor server, making phishing attacks highly credible. This constitutes a multi-tenant isolation breach with significant integrity impact, enabling cross-customer email spoofing, phishing, and potential reputational damage to affected domain owners (GitHub Advisory).

A proof-of-concept exploit is publicly available in the GitHub Security Advisory, consisting of concrete curl commands demonstrating how to add a cross-customer sender alias via the Froxlor API. Exploitation requires only a valid authenticated customer account and that the mail.enable_allow_sender feature is enabled on the Froxlor instance. The EPSS score is approximately 0.025% (very low), and there is no evidence of active in-the-wild exploitation or CISA KEV catalog listing as of the time of publication (GitHub Advisory).

1. Reconnaissance: Identify a multi-tenant Froxlor instance (version < 2.3.6) with mail.enable_allow_sender enabled. Obtain a valid customer account (Customer A) on the target instance.
2. Identify target domain: Determine an email address on a domain owned by another customer (Customer B), e.g., ceo@domain-b.com.
3. Send malicious API request: As Customer A, issue a POST request to the Froxlor API to add the cross-customer address as an allowed sender alias:

curl -X POST 'https://froxlor-host/api/v1/' \
  -H 'Authorization: Basic <Customer_A_credentials>' \
  -H 'Content-Type: application/json' \
  -d '{
    "command": "EmailSender.add",
    "params": {
      "emailaddr": "myaccount@domain-a.com",
      "allowed_sender": "ceo@domain-b.com"
    }
  }'

4. Bypass validation: The server passes ceo (the local part) instead of domain-b.com to validateLocalDomainOwnership(). Since no domain named ceo exists, the check passes silently and the alias is inserted into mail_sender_aliases.
5. Verify alias creation: Confirm the alias was created using EmailSender.listing via the API.
6. Send spoofed email: Connect to the Froxlor mail server via SMTP as Customer A's mail account and set the MAIL FROM address to ceo@domain-b.com. Postfix's sender_login_maps authorizes this because the alias entry now maps ceo@domain-b.com to Customer A's account (GitHub Advisory).

• Network: Unexpected SMTP sessions from a customer mail account using a MAIL FROM address on a domain not owned by that customer; API POST requests to /api/v1/ with EmailSender.add command and allowed_sender values referencing foreign domains.
• Logs: Froxlor application logs showing successful EmailSender.add calls where the allowed_sender domain does not match any domain owned by the requesting customer; Postfix logs (mail.log) showing sender_login_maps matches for cross-customer sender addresses.
• Database: Rows in the mail_sender_aliases table where the domain portion of allowed_sender does not belong to the same customer as the associated email address.

Upgrade Froxlor to version 2.3.6 or later, which fixes the issue by changing array index [0] to [1] on line 100 of lib/Froxlor/Api/Commands/EmailSender.php, ensuring the domain part of the email address is correctly passed to validateLocalDomainOwnership() (Patch Commit, Release Notes). As an interim measure for instances that cannot be immediately upgraded, administrators should audit the mail_sender_aliases database table for any entries where the allowed_sender domain does not belong to the same customer as the associated email account, and remove unauthorized aliases. Disabling the mail.enable_allow_sender feature entirely will also prevent exploitation until the patch is applied.

The vulnerability was disclosed via a GitHub Security Advisory by Froxlor maintainer d00p on April 15, 2026, and patched in the same release cycle. The 2.3.6 release was labeled a "security release" and addressed multiple security issues simultaneously (Release Notes). No significant broader media coverage or notable researcher commentary beyond the official advisory has been identified.