CVE-2026-74865 in SOGo
Summary
by MITRE • 09/30/2026
sogo_yhn configures SOGo with a parameter "SOGoTrustProxyAuthentication=YES". This causes the password to be bypassed during HTTP Basic authentication. An unauthenticated attacker who provides the username of an existing user and any arbitrary password can successfully log in to that user's account.
This issue was fixed in version 5.8.0~ynh9.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/30/2026
The vulnerability described involves a critical misconfiguration within the SOGo groupware suite, specifically related to how it handles HTTP Basic authentication when operating behind a reverse proxy or load balancer. The root cause lies in the configuration parameter "SOGoTrustProxyAuthentication" being set to YES. This setting is designed for environments where an external trusted proxy performs initial authentication and passes the authenticated user's identity via specific headers, such as REMOTE_USER or HTTP_AUTHORIZATION, allowing SOGo to trust that pre-authenticated state without requiring a second password entry from the end-user client. However, when this parameter is enabled inappropriately—such as in direct access scenarios where no trusted proxy exists—the application logic fails to distinguish between requests originating from a verified internal source and those coming directly from external clients.
This architectural flaw results in a complete bypass of the authentication mechanism for HTTP Basic Auth flows. An unauthenticated attacker can exploit this by sending an HTTP request containing only the target username within the Authorization header, while providing any arbitrary string as the password component. Because SOGo trusts the proxy flag and does not strictly validate that the incoming connection actually originated from a trusted internal IP or proxy server before accepting the pre-authenticated state, it accepts these credentials as valid. This effectively allows an attacker to impersonate any existing user in the system simply by knowing their username, without needing access to their actual password hash or having performed any brute-force attack against the credential store.
The operational impact of this vulnerability is severe, leading directly to unauthorized access and potential data breach. Since SOGo typically manages email, calendars, contacts, and tasks for organizations, gaining access via this method grants an attacker full control over the victim's account. This can lead to the exfiltration of sensitive corporate communications, exposure of personal schedules and contact lists, and further lateral movement within the network if the compromised credentials are used to authenticate against other integrated services such as LDAP directories or database backends. The ease of exploitation means that automated scanning tools could rapidly identify vulnerable instances across the internet by simply probing for this specific authentication bypass condition using common usernames like admin or root paired with dummy passwords.
From a classification perspective, this issue aligns with CWE-287: Improper Authentication, as the system fails to properly verify credentials before granting access. It also relates to CWE-306: Missing Authentication for Critical Function, since the authentication process is bypassed entirely rather than being weak or flawed in its execution logic alone. In terms of MITRE ATT&CK framework tactics, this vulnerability facilitates Initial Access through Valid Accounts (T1078), allowing adversaries to establish a foothold without detection by traditional credential-based intrusion detection systems that might not flag the absence of a password mismatch error since the system technically accepts the input as valid due to the misconfiguration.
Mitigation strategies must focus on correcting the application configuration and hardening network architecture. The primary fix is to ensure SOGoTrustProxyAuthentication is set to NO unless there is a verified, secure reverse proxy in front of the service that explicitly handles authentication and passes trusted headers from whitelisted IP addresses. If this feature is required for performance or usability reasons behind a legitimate proxy, administrators must implement strict network-level controls such as firewall rules restricting access to SOGo ports exclusively to the known internal IPs of the proxy servers. Additionally, deploying Web Application Firewalls (WAFs) can help detect and block anomalous authentication patterns that do not follow expected traffic flows from trusted sources. The vulnerability was addressed in version 5.8.0~ynh9, so upgrading to this patched release is essential for systems where the configuration cannot be immediately corrected or if there is uncertainty about the deployment topology's security posture.