Summary
Ente's emergency recovery API insufficiently scoped approval, rejection, and stop-recovery actions to the authenticated user and the targeted recovery session. An accepted emergency contact could advance another user's recovery session before its configured notice period expired, while knowledge of a session UUID could potentially allow unauthorized cancellation.
Ente's emergency recovery API insufficiently scoped approval, rejection, and stop-recovery actions to the authenticated user and the targeted recovery session. An accepted emergency contact could advance another user's recovery session before its configured notice period expired, while knowledge of a session UUID could potentially allow unauthorized cancellation.
Affected context
The issue occurs in Ente server deployments using emergency recovery workflows before the relevant authorization checks were corrected. Risk exists when recovery-transition endpoints trust a client-supplied user identifier or recovery-session UUID without confirming that the authenticated actor is authorized for the specific session and account. Approval exploitation also depends on the attacker having previously been added and accepted as the victim's emergency contact.
The issue occurs in Ente server deployments using emergency recovery workflows before the relevant authorization checks were corrected. Risk exists when recovery-transition endpoints trust a client-supplied user identifier or recovery-session UUID without confirming that the authenticated actor is authorized for the specific session and account. Approval exploitation also depends on the attacker having previously been added and accepted as the victim's emergency contact.
Exploit preconditions
- Attack surface: Authenticated emergency recovery API endpoints
- Required access: An authenticated account accepted as an emergency contact for the victim's account to abuse approval; knowledge of another session UUID may be sufficient to target rejection or stop transitions, depending on deployment controls
- Trigger point: POST requests that approve, reject, or stop an emergency recovery session
- Why exploitation is possible: The server uses client-supplied identity or session identifiers without consistently enforcing ownership and relationship checks before changing session state
- Attack surface: Authenticated emergency recovery API endpoints
- Required access: An authenticated account accepted as an emergency contact for the victim's account to abuse approval; knowledge of another session UUID may be sufficient to target rejection or stop transitions, depending on deployment controls
- Trigger point: POST requests that approve, reject, or stop an emergency recovery session
- Why exploitation is possible: The server uses client-supplied identity or session identifiers without consistently enforcing ownership and relationship checks before changing session state
Why this happens
The underlying bug is an object-level authorization failure mapped to CWE-639: Authorization Bypass Through User-Controlled Key. Sensitive recovery-session updates were selected using identifiers supplied by the client, but authorization was not sufficiently bound to the authenticated principal, the emergency-contact relationship, and the specific target session. As a result, a caller with partial legitimate access could cause state transitions on an account or session outside the caller's authorized scope.
The underlying bug is an object-level authorization failure mapped to CWE-639: Authorization Bypass Through User-Controlled Key. Sensitive recovery-session updates were selected using identifiers supplied by the client, but authorization was not sufficiently bound to the authenticated principal, the emergency-contact relationship, and the specific target session. As a result, a caller with partial legitimate access could cause state transitions on an account or session outside the caller's authorized scope.
Potential impact
- An accepted emergency contact could advance a victim's recovery session prematurely
- Account recovery information may become available before the owner-configured notice period expires
- An attacker could continue recovery activity within the affected account's workflow
- A caller who obtains another session UUID could potentially cancel or disrupt that recovery session
- Recovery workflows may be abused for denial of service or account-access disruption
- An accepted emergency contact could advance a victim's recovery session prematurely
- Account recovery information may become available before the owner-configured notice period expires
- An attacker could continue recovery activity within the affected account's workflow
- A caller who obtains another session UUID could potentially cancel or disrupt that recovery session
- Recovery workflows may be abused for denial of service or account-access disruption
General mitigation guidance
Mitigation generally focuses on enforcing server-side, object-level authorization for every recovery-session transition.
Common defensive patterns include:
- Deriving the acting identity from the authenticated session rather than trusting client-supplied user identifiers
- Verifying that the caller is an authorized participant in the exact recovery session being modified
- Binding emergency-contact permissions to the intended victim account and permitted transition
- Treating session UUIDs as references, not as authorization credentials
- Enforcing state-transition rules and notice periods on the server before changing recovery status
- Applying least privilege and minimizing recovery information returned to emergency contacts
- Using consistent authorization middleware and deny-by-default policies across approve, reject, and stop operations
Mitigation generally focuses on enforcing server-side, object-level authorization for every recovery-session transition.
Common defensive patterns include:
- Deriving the acting identity from the authenticated session rather than trusting client-supplied user identifiers
- Verifying that the caller is an authorized participant in the exact recovery session being modified
- Binding emergency-contact permissions to the intended victim account and permitted transition
- Treating session UUIDs as references, not as authorization credentials
- Enforcing state-transition rules and notice periods on the server before changing recovery status
- Applying least privilege and minimizing recovery information returned to emergency contacts
- Using consistent authorization middleware and deny-by-default policies across approve, reject, and stop operations
How teams detect issues like this
High-level detection can include:
- Static analysis for update or state-transition queries keyed only by request parameters
- Code review checks for client-controlled user IDs or session UUIDs used without ownership validation
- API policy tests covering cross-user and cross-session authorization attempts
- Monitoring for recovery transitions where the authenticated actor is not a verified participant
- Alerts for repeated attempts to manipulate recovery sessions belonging to other accounts
- Automated security review tools that identify missing object-level authorization checks
High-level detection can include:
- Static analysis for update or state-transition queries keyed only by request parameters
- Code review checks for client-controlled user IDs or session UUIDs used without ownership validation
- API policy tests covering cross-user and cross-session authorization attempts
- Monitoring for recovery transitions where the authenticated actor is not a verified participant
- Alerts for repeated attempts to manipulate recovery sessions belonging to other accounts
- Automated security review tools that identify missing object-level authorization checks
