Froxlor EUVD-2026-87691

Requires: (1) an authenticated Froxlor customer account with API access; (2) the administrator to have enabled the allowed-sender feature (mail.enable_allow_sender=1) while disabling external allowed-sender domains (mail.allow_external_domains=0) - this specific configuration is the whole precondition; and (3) the generated mail configuration to actually consume the allowed-sender table for the spoofing impact to materialize. Limiting factors: exploitation needs valid low-privilege API credentials (not unauthenticated), the non-default policy combination described above, and the practical impact (sender spoofing) depends on the downstream mail-config generation honoring the table.

This is a genuine but modest-severity authorization/policy-enforcement flaw, not a high-urgency issue. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) confirms network-reachable, low-complexity exploitation but requires an authenticated customer account with API access (PR:L), so it is not remotely exploitable by anonymous attackers. There is no EPSS score, no CISA KEV listing, and no public POC identified at time of analysis, so this is 'no public exploit identified at time of analysis.' The vendor CVSS 4.0 of 7.1 is driven by VI:H (high integrity impact), which is generous: the actual outcome is registration of an unauthorized allowed-sender identity that merely FACILITATES sender spoofing, and only 'where the generated mail configuration consumes the allowed-sender table' - a conditional, downstream effect rather than direct high-integrity compromise. A more defensible integrity impact is Low. There is no confidentiality or availability impact. Net: a real defense-in-depth policy bypass worth patching in mail-hosting deployments, but low real-world priority given the auth requirement, conditional impact, niche product footprint, and absence of any exploitation signal.

An administrator enables the allowed-sender feature but disables external domains (mail.enable_allow_sender=1, mail.allow_external_domains=0), expecting customers to only send as their own hosted domains. An authenticated customer with API access calls EmailSender.add to register an arbitrary external address (e.g. billing@a-bank.example), which is stored despite the policy; once the generated mail configuration consumes the allowed-sender table, the customer can send mail spoofing that external identity. No public POC exists.