emailflare EUVD-2026-116588

Requires a valid authenticated account with 'member' or 'tester' role on a vulnerable emailflare instance; admin/super-admin are not needed and no user interaction is involved. Against pre-cf31f33 code the POST /api/inbox/compose handler performs no ownership check on the supplied from address, so any such account can set an arbitrary sender. The fix restricts members/testers to inboxes they belong to in inbox_members and rejects senders not matching a configured inbox. Limiting factors that reduce real-world risk: exploitation is confined to authenticated principals (so an attacker must already have org access), impact is limited to outbound sender spoofing/impersonation (integrity only), and the product is a niche, small-footprint project.

This is a moderate, real-but-bounded priority rather than a drop-everything emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) describes a network-reachable endpoint that is trivially triggerable but requires an authenticated low-privilege account (PR:L), so exploitation is gated to existing org members/testers - not anonymous internet attackers. Impact is confined to integrity (VI:H) with no confidentiality or availability loss (VC:N/VA:N), consistent with a sender-spoofing/impersonation flaw rather than code execution or data theft. The vuln.today priority of 'this_week' aligns with that profile. There is no EPSS score, no CISA KEV listing, and no public exploit identified at time of analysis - the only code reference is the fixing commit, not a weaponized PoC - so exploitation status is 'no public exploit identified at time of analysis.' The Tags field says 'Authentication Bypass,' which conflicts with the description and CWE-862 (Missing Authorization): authentication is intact and required; it is the authorization check on the sender address that is absent. Net: a genuine abuse-of-trust/BEC-style risk for anyone running emailflare, but constrained by the authentication requirement and the product's very small deployment footprint.

An authenticated member (or tester) of an emailflare instance sends a POST to /api/inbox/compose with an arbitrary from field set to an address they do not own - e.g. a company executive or the organization's official inbox. Because the sender is passed unchecked to the Cloudflare send call, the spoofed mail is delivered to external recipients, enabling convincing phishing or business-email-compromise. No public exploit is identified at time of analysis; the attack is low-complexity and needs only a valid low-privilege account.