CVE-2026-16751: Account Takeover in Ente via Emergency-Contact Recovery Bypass

Background: the one feature that is supposed to be safe

Ente is a privacy-first, end-to-end encrypted service for photos, authentication codes (Ente Auth), and passwords and secrets (Ente Locker). Its whole promise is that nobody — not even Ente — can reach your data without your keys.

Emergency contacts are the deliberate exception. You nominate someone you trust, and during that setup your recovery key is intentionally wrapped to their public key, so that if you are ever locked out they can help you recover. Because that is a genuine break-glass capability, Ente puts a delay in front of it: a recovery started by an emergency contact enters a waiting period during which you are notified and can reject it. The waiting period is the entire safety mechanism. It is what separates "a trusted contact can help me recover" from "a former trusted contact can silently seize my account."

Root cause: the approval step never checks ownership

Emergency recovery moves through a small state machine: a contact starts a recovery, it waits, then it becomes ready, then the password can be changed. The bug is in the step that moves a recovery from waiting to ready.

The approval handler checks that the caller claims to be approving as themselves. What it never does is load the recovery session named in the request and confirm that session actually belongs to them. It takes the session identifier straight from the request body and passes it to a database update that filters only on the session id and its current status — with no constraint tying the session to the caller.

// approve handler — updates by session id + status only,
// with no check that the session belongs to the caller.
UPDATE emergency_recovery
   SET status = 'ready', ready_at = now()
 WHERE session_id = :sessionIdFromRequestBody
   AND status = 'waiting';

So any known waiting session can be flipped to ready by anyone, and the ready state resets the wait timer to now. Downstream, the safety check only enforces the waiting period while the status is still waiting. Once the row is flipped to ready, that check is simply skipped. The password-change step then proceeds, and as part of completing recovery it disables the victim's TOTP two-factor and removes their passkey two-factor, with no further ownership check.

The attacker can already decrypt the victim's recovery key, because during the legitimate emergency-contact setup the victim's key was deliberately wrapped to the attacker's public key. That is the intended design — the waiting period was the only thing keeping it in check.

There is also a smaller companion issue: the "recovery approved" notification is addressed using the attacker-supplied identifier rather than the real session owner, so the notification goes to the attacker instead of the victim. The victim gets no signal that their safety window was just skipped.

Exploitation

Prerequisite: the attacker was, at some earlier point, legitimately added as the victim's emergency contact and accepted. This is a normal, expected use of the feature — not something the attacker has to trick the victim into at attack time.

The chain runs in seconds:

1. The attacker logs in normally and starts a recovery for the victim's account. The system creates a waiting session with a 30-day timer and emails the victim. The attacker does not wait.
2. The attacker reads back their own recovery sessions through a normal info endpoint, which returns the new session's identifier.
3. The bug: the attacker calls the approve-recovery endpoint with that session id, claiming to approve as themselves. The missing ownership check lets it through, and the session flips from waiting to ready with the wait timer reset to now.
4. The attacker initiates and then completes a password change on the victim's account. Ente's recovery flow disables the victim's TOTP and passkey two-factor as part of the process, and the victim's credentials are replaced.

At the end of this, the attacker controls the account. The victim may not even have opened the email that was supposed to warn them.

Impact

• Full account takeover of any user who ever added the attacker as an emergency contact.
• The one protection on the feature — the multi-day notice plus the ability to reject — is bypassed completely.
• The victim's end-to-end encrypted photos, their Ente Auth two-factor seeds (which protect all their other accounts — bank, email, everything), and their Ente Locker secrets become accessible to the attacker.
• The victim's own two-factor protections are wiped by the recovery flow itself.
• Applies to hosted Ente (api.ente.io) and to every self-hosted deployment.

The reason this is more than a single-app compromise: whoever takes over an Ente Auth account can read the 2FA seeds that guard the victim's other accounts. The blast radius extends well past Ente.

CVSS vector rationale

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

• AV:N — The recovery API is reachable over the network.
• AC:L — Start a recovery, read back the session id, flip it to ready. No special conditions.
• PR:L — The attacker needs a normal account that was previously accepted as the victim's emergency contact.
• UI:N — No victim interaction. The attacker does not wait for, and does not need, any victim action; the warning email can go unread.
• S:C (Scope Changed) — Compromise of the emergency-recovery component yields control of the victim's whole account, and via Ente Auth, the security of the victim's other services.
• C:H — End-to-end encrypted photos, 2FA seeds, and Locker secrets are exposed.
• I:H — Password reset and credential replacement on the victim's account.
• A:H — The victim is locked out of their own account and their two-factor is wiped.

Remediation

The vendor fixed the issue in PR #11311. The fix loads the recovery session and verifies it belongs to the account and contact named in the request before allowing the status change, and enforces that the session is genuinely in the waiting state.

1. Hosted users on api.ente.io are already covered by the vendor patch.
2. Self-hosted operators should update to a build that includes PR #11311.
3. Audit recovery records for sessions that moved from waiting to ready faster than the configured notice period — that timing gap is the fingerprint of this bug being exercised.

Disclosure timeline

• 2026-05-27 — Vulnerability discovered during a focused audit of the Ente server, and reported privately through GitHub's security advisory flow, with parallel notice to Ente security and a CERT/CC case (VU#834187).
• 2026-07-08 — Ente confirmed the issue and reported it fixed in PR #11311.
• 2026-07-23 — CERT/CC reserved CVE-2026-16751 for the issue.
• 2026-07-26 — Coordinated public disclosure (CERT/CC VU#834187 and this write-up).

References

• CERT/CC vulnerability note: VU#834187
• GitHub Security Advisory: GHSA-9jcx-2fcp-hxmf
• Vendor fix: ente-io/ente PR #11311
• Ente project: ente.io
• Blog post (story and disclosure narrative): The Safety Window That Closed in One Request: CVE-2026-16751 in Ente

Found and reported by Louis Sanchez, Founder & Principal Security Consultant at Voke Cyber (OSCP, OSWA, CISSP, CCSK). Prior advisories: Cal.com webhook plant, CVE-2026-15630 (Casdoor), CVE-2026-39878 (Chamilo), CVE-2026-48742 (Coolify), and CVE-2026-35198 (HeyForm).