Ente Server CVE-2026-104875

Exploitation requires the attacker to already be an emergency contact that the victim previously ADDED AND ACCEPTED - the bug does not grant recovery rights over arbitrary accounts. Given that relationship, the attacker calls POST /emergency-contacts/approve-recovery supplying their own client-controlled userID plus a recovery-session UUID; the pre-fix server authorized on those client-supplied values and updated the row by UUID alone (CWE-639), letting the attacker move the session WAITING→READY, clear wait_till, and bypass the owner-configured notice period to retrieve recovery information. A secondary variant affects the reject/stop transitions: any user who KNOWS another recovery-session UUID could cancel a session they are not party to. Limiting factors: authenticated access as an established, victim-approved contact is mandatory; the attack is inherently targeted to that one relationship; the notice-period bypass only accelerates an already-authorized recovery path rather than creating one; and all vectors are closed in server image 2026.07.09.

Signals point to a moderate, conditional risk rather than a drop-everything emergency. The CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:R) describes a network-reachable but authenticated attack of high complexity: the attacker must already be an accepted emergency contact of the specific victim, which is why PR:L and AC:H apply and why impact is bounded to victims who deliberately onboarded the attacker. Impact is genuinely high once conditions are met (C:H/I:H/A:H - the flaw clears the owner-configured waiting period and yields recovery of an end-to-end-encrypted account, i.e. account takeover). There is no KEV listing and no EPSS score in the provided data, so 'no public exploit identified at time of analysis' applies - the only public code consists of the vendor FIX commits and PRs, which demonstrate the root cause (CWE-639, user-controlled userID/session UUID trusted without ownership checks) but are not weaponized exploit code. The required pre-existing, victim-initiated trust relationship makes this inherently targeted rather than mass-exploitable, further lowering real-world urgency. Note the precondition tension: the input marks UI:R, but the 'user interaction' is really the victim's prior one-time acceptance of the attacker as a contact (a precondition), not interaction during exploitation - verify intent with the vendor advisory GHSA-2hxj-953x-c2vw. EPSS and KEV data are absent and should be checked before final prioritization.

A person the victim previously added and accepted as an emergency contact initiates account recovery, then sends a crafted POST /emergency-contacts/approve-recovery request supplying their own userID and the recovery-session UUID. Because the server authorized on the client-supplied identifiers and updated the session by UUID alone, the attacker transitions the victim's session from WAITING to READY and clears wait_till, skipping the owner-configured notice period and continuing to recover the victim's end-to-end-encrypted account. No weaponized public exploit exists - only the vendor's fix commits are public.