CVE-2026-93453: 
SOGo vulnerability analysis and mitigation

CVE-2026-93453 is a weak password recovery mechanism vulnerability in Alinto SOGo that allows unauthenticated attackers to intercept password-reset tokens by supplying a malicious Origin HTTP header. All SOGo versions before 5.12.11 are affected. The vulnerability was published on September 18, 2026, with a patch released in SOGo 5.12.11. It carries a CVSS v3.1 score of 8.3 (High) and a CVSS v4.0 score of 8.7 (High) (Github Advisory, Feedly).

The root cause is classified as CWE-640 (Weak Password Recovery Mechanism for Forgotten Password). In the vulnerable code path within UI/MainUI/SOGoRootPage.m (line 1375 of SOGo 5.12.10), the passwordRecoveryEmailAction method constructs the password-reset URL by directly interpolating the client-supplied Origin HTTP request header as the base URL authority, without any server-side validation: url = [NSString stringWithFormat:@"%@%@?token=%@", [[request headers] objectForKey:@"origin"], [request uri], jwtToken]. An unauthenticated attacker can send a password recovery request for any victim account with a crafted Origin header pointing to attacker-controlled infrastructure, causing the server to embed a valid JWT reset token into a link mailed to the victim's recovery address (Commit 382118a, Commit 04a3e98).

Successful exploitation enables complete account takeover of any SOGo user account for which password recovery is enabled. The attacker captures a valid, server-issued JWT password-reset token without any prior authentication or access to the victim's mailbox — only the victim's email address is required to initiate the attack. Confidentiality and integrity of the affected account are fully compromised (CVSS confidentiality: High, integrity: High), and because SOGo is a groupware platform handling email, calendaring, and contacts, account takeover may expose sensitive organizational communications and enable further lateral movement within connected systems (Github Advisory, Feedly).

There is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation at the time of disclosure. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. The attack requires no privileges and only passive user interaction (the victim must click the malicious reset link), making it relatively straightforward to weaponize once an attacker identifies a target's email address (Github Advisory, Feedly).

1. Reconnaissance: Identify a SOGo instance running a version prior to 5.12.11 with password recovery enabled (SOGoPasswordRecoveryEnabled = YES). Obtain the target victim's email address (e.g., from public directories or OSINT).
2. Set up attacker infrastructure: Stand up a web server at an attacker-controlled domain (e.g., https://attacker.example.com) capable of logging incoming HTTP requests, including query parameters.
3. Craft the malicious password recovery request: Send an HTTP POST request to the SOGo password recovery endpoint (e.g., /SOGo/so/passwordRecoveryEmail) with the victim's username/email in the request body and a spoofed Origin header set to the attacker's domain:

   POST /SOGo/so/passwordRecoveryEmail HTTP/1.1
   Host: sogo.victim.org
   Origin: https://attacker.example.com
   Content-Type: application/json
   
   {"username": "victim@victim.org", ...}

4. Token delivery to attacker: The vulnerable SOGo server constructs the reset URL as https://attacker.example.com/SOGo/so/passwordRecoveryEmail?token=<JWT> and emails it to the victim's recovery address.
5. Token capture: When the victim clicks the link (believing it is legitimate), their browser sends the request to the attacker's server, which logs the token query parameter containing the valid JWT reset token.
6. Account takeover: The attacker uses the captured JWT token against the legitimate SOGo server's password reset endpoint to set a new password and gain full access to the victim's account (Commit 382118a, Github Advisory).

• Network: Outbound password recovery emails containing reset links pointing to domains other than the legitimate SOGo server's hostname; HTTP POST requests to the SOGo password recovery endpoint originating from unexpected or anonymous IP addresses with a suspicious Origin header value differing from the server's own domain.
• Logs: SOGo application logs showing passwordRecoveryEmailAction invocations where the Origin header does not match the configured server URL; on patched systems (5.12.11+), log entries containing "Password recovery exception for user %@: invalid request header" indicate attempted exploitation.
• Email: Victim users reporting receipt of password reset emails with links pointing to unfamiliar or external domains instead of the organization's SOGo server.
• Authentication: Unexpected successful password changes or logins for user accounts shortly after password recovery emails were sent, particularly from new IP addresses or geolocations (Commit 04a3e98).

Upgrade SOGo to version 5.12.11 or later, which fixes the vulnerability via two commits: the server now uses [[context serverURL] absoluteString] instead of the client-supplied Origin header, and additionally validates the Origin header against a new administrator-configured allowlist (SOGoPasswordRecoveryBaseURLs). As a mandatory post-upgrade configuration step, administrators must set the SOGoPasswordRecoveryBaseURLs parameter in sogo.conf to a list of permitted base URLs (e.g., SOGoPasswordRecoveryBaseURLs = ("https://sogo.example.org");); leaving this setting empty or unset will cause password recovery to return a 403 error. As an interim workaround prior to patching, disabling password recovery (SOGoPasswordRecoveryEnabled = NO) eliminates the attack surface entirely (Commit 04a3e98, Github Advisory).