Advisory · CVE-2026-127111
Unauthenticated password-recovery brute force enables SOGo account takeover
SOGo before 5.12.13 lets an unauthenticated attacker guess secret-question answers without lockout, obtain a password-recovery token, and take over accounts. NVD rates it critical at CVSS 9.1.
- Vendor
- Alinto
- Product
- SOGo
- Identifier / CWE
- CVE-2026-127111
CWE-307 - Action timing
- Immediate
Explain it like I’m five
SOGo asks a secret question to prove you forgot your password, but it never stops you from guessing. An attacker can keep guessing until one answer works, then use that to set a new password and walk in as you.
- 01Recovery endpoint
An unauthenticated attacker calls the SOGo passwordRecoveryCheck endpoint for a target account.
- 02Unlimited guesses
The endpoint applies no lockout or rate limiting, so the attacker submits candidate secret-question answers without limit.
- 03Recovery token issued
A correct guess returns a valid password-recovery JWT for the account.
- 04Password reset and login
The attacker uses the token to set a new password without the old credential and logs in through the connect endpoint, taking over the account.
What happened
SOGo releases before 5.12.13 contain an improper restriction of excessive authentication attempts (CWE-307) in the password-recovery flow. NVD describes the flaw as allowing unauthenticated attackers to reset account passwords by repeatedly guessing secret-question answers through the passwordRecoveryCheck endpoint, with no lockout or rate limiting. A correct guess yields a valid recovery JWT, which the attacker then uses to change the account password and log in, achieving full account takeover on accounts without TOTP enabled. NVD rates it critical at CVSS 9.1.
The SOGo 5.12.13 release notes state that several vulnerabilities, some critical, were fixed in that version, that the flaws affect any previous version, and that users should update as soon as possible.
A missing lockout on a recovery endpoint is worse than a missing lockout on login: the login page is usually the guarded door, while recovery is a side door that hands out the keys. Any SOGo deployment with password recovery enabled and accounts not protected by TOTP should treat this as an active exposure until upgraded.
What to do
- Inventory every SOGo deployment and confirm the running version.
- Upgrade affected instances (before 5.12.13) to SOGo 5.12.13 or later.
- Until patched, restrict network access to SOGo, especially internet-facing instances, and consider disabling password recovery if it is not needed.
- Review SOGo logs for repeated passwordRecoveryCheck requests, bursts of failed secret-question answers, and password resets followed by logins from unfamiliar sources.
- For any account showing suspicious recovery activity, force a password reset, review the account for changes, and rotate credentials reachable from it.
- Verify the deployed version after remediation and confirm recovery attempts are now rate limited.
Management note
An unauthenticated path to full account takeover with no lockout is a patch-first problem, not a monitoring problem. Upgrade SOGo, then check whether any accounts were recovered by someone who should not have been able to.