version 5.12.11 fixes a serious vulnerability in the recovery function , which could lead to interception of valid links and ultimately account takeover. The vulnerability affects installations prior to version 5.12.11 and exploits trust in customer-controlled data.
The vulnerability is documented as CVE-2026-93453 and is attributed to incorrect use of the HTTP Origin when creating recovery messages. According to the CVE listing, an unidentified attacker could set a malicious destination for the link sent to the user.
See also: Keycloak: Critical vulnerability allows complete account takeover
The recovery function in SOGo 5.12.11
SOGo offers a password recovery feature via email. When the user requests a new link, the server must generate an address that points exclusively to the legitimate installation. However, in vulnerable versions, the value of the Origin header could affect the beginning of this address.
With a specially crafted request, the attacker could declare their own domain as the origin. The recovery message would still be sent to the victim's real address, but the link would lead to infrastructure controlled by the attacker. If the user followed the link, the valid recovery token could be revealed.
The Origin header describes the origin of a web request, but is not proof of identity in itself. When used to construct a secure link without strong authentication, it becomes a checkpoint for an attacker. The issue is particularly critical in shared installations, where the same server serves multiple domains.
The attack does not require a previous login to SOGo, but it does involve social engineering: the target must open the message or use the link they received. The result can be a password change and loss of control of the account, especially when there is no second factor of authentication.
What does the new version fix?
The official SOGo announcement states that version 5.12.11 fixes three major vulnerabilities affecting previous versions. For password recovery functionality, administrators must explicitly declare allowed base URLs via the SOGoPasswordRecoveryBaseURLs.
This setting is required when SOGoPasswordRecoveryEnabled. Alinto warns that there is no safe default value and that the service may reject requests when allowed addresses are not set. Addresses should not end with a slash character.
The SecNews technical team recommends immediately upgrading SOGo to version 5.12.11 or later and checking all servers that expose the recovery page to the internet. In addition, administrators should review logs for restore requests with unusual Origin headers and inform users of suspicious links.
Until the upgrade is complete, access to the recovery function from untrusted networks can be temporarily restricted, as long as it does not disrupt critical services. The temporary solution is not a substitute for installing the patched version, because attackers can exploit other routes related to account management.
See also: Zimbra zero-click exploit: Stealing emails and 2FA passwords
Immediate actions for administrators
After installing SOGo 5.12.11, you should check the SOGoPasswordRecoveryBaseURLs and confirm that it only includes domains that belong to your organization. Changing passwords alone is not enough if the service is still creating links based on untrusted origins. It is also recommended to keep the logs before the upgrade so that you can compare requests and look for potential abuse.
🔑 Secure your passwords with Proton Pass
Password manager from Proton — end-to-end encryption, passkeys, built-in 2FA, and monitoring for leaks of your credentials.
- ✔ Encrypted storage of passwords & passkeys
- ✔ Notification if any of your passwords are leaked (Dark Web Monitoring)
- ✔ Free version — on all devices
The link is an affiliate link — SecNews may receive a commission at no additional cost to you. It does not affect the independence of our article writing.
Organizations should recall active sessions, enable multi-factor authentication where available, and review recent password changes. The relevant source code change indicates that the fix is related to the secure construction of recovery emails.
See also: Vulnerability in Flowise allows account token theft
This vulnerability illustrates why recovery links should be based on fixed, verified addresses rather than headers that can be modified by the request sender. For those using SOGo, upgrading and properly configuring allowed addresses is a necessary protective step.
