emailflare CVE-2026-121729

Requires a valid authenticated account on the emailflare inbox service - exploitation works even for the lowest-privileged 'member' (or 'tester') role, since the /api/keys list/create/revoke routes performed no role or ownership authorization before commit cf31f33. No special non-default configuration is needed: the pre-patch code defaulted new keys to 'global' scope, so a member could mint a global live key accepted by /v1/send for any domain. The exploitation limit is that the attacker must already be an authenticated tenant member (PR:L, no anonymous access) and the instance must be running code before commit cf31f33; the fix adds verifyInboxSender role/ownership enforcement and changes the default key scope to 'domain', so patched or admin-restricted deployments are not exposed.

The input supplies a CVSS 4.0 vector (7.2) with AV:N/AC:L/AT:N/PR:L/UI:N and impact VC:L/VI:H/VA:H, meaning a network-reachable, low-complexity flaw that nonetheless requires an authenticated account (PR:L) - exploitation is not open to anonymous internet attackers. The decision label is this_week, which signals meaningful but non-emergency urgency. No EPSS score, no CISA KEV listing, and no PoC/exploit reference are present in the input: there is no public exploit identified at time of analysis and no evidence of active exploitation, so the signals are consistent rather than conflicting. The real driver of risk is the integrity and availability impact (VI:H/VA:H): a low-privileged member can mint a global live API key that /v1/send accepts to spoof mail from any domain, or revoke keys to break integrations - a genuine privilege-escalation/authorization gap rather than a merely inflated high-CVSS issue. The limiting factor keeping this off an emergency footing is the authentication requirement (PR:L) and the product's apparently small deployment footprint; EPSS and SSVC automatable/exposure metrics are not provided, so widespread opportunistic exploitation cannot be inferred from the available data.

A user holding only a low-privileged member account on an emailflare inbox service calls the unprotected /api/keys create route and mints a global, live-scoped API key. They then present that key to /v1/send to send mail from any domain the platform serves (enabling spoofing/phishing), or instead revoke existing keys to disable legitimate integrations. No public exploit code is referenced; exploitation requires an authenticated session but only trivial request crafting (AC:L).