CVE-2026-74864 in sogo_yhn
Summary
by MITRE • 09/30/2026
sogo_yhn configures SOGo with a parameter that forces the request with HTTP header "x-webobjects-remote-user" to be treated as sent by a verified user without performing password validation. Since Nginx does not strip this header, any client can supply it arbitrarily and gain access as any user, including a privileged user, without providing a password.
This issue was fixed in version 5.8.0~ynh9.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/30/2026
The vulnerability described constitutes a critical authentication bypass flaw within the SOGo collaborative groupware server when deployed via the YunoHost packaging system. The core technical failure lies in how SOGo processes HTTP headers to determine user identity, specifically regarding the x-webobjects-remote-user header. This header is intended for use by reverse proxies or load balancers that have already performed authentication and wish to pass the authenticated username downstream to the application server. However, the specific configuration variant identified here fails to enforce strict validation of this header's origin. Instead of verifying that the request originated from a trusted internal proxy with valid credentials, SOGo blindly accepts any value provided in this header as proof of identity. This design oversight effectively neutralizes the authentication mechanism for any client capable of crafting custom HTTP requests, allowing an attacker to impersonate any user account on the system simply by injecting the desired username into the request headers.
From a technical perspective, this issue stems from a lack of input validation and trust boundary enforcement between the web server layer and the application logic. In standard secure architectures, reverse proxies such as Nginx are configured to strip sensitive authentication headers before forwarding requests to backend applications like SOGo. This prevents end-users from spoofing these headers directly. However, in this specific configuration scenario, Nginx is not stripping the x-webobjects-remote-user header. Consequently, any external client can send a request with arbitrary values for this header, and SOGo will interpret it as a legitimate authentication signal. The absence of password validation or session token verification means that no cryptographic proof of identity is required to gain access. This represents a fundamental breakdown in the principle of least privilege and secure default configurations, where administrative controls are inadvertently exposed to unauthenticated actors through misconfigured proxy behavior.
The operational impact of this vulnerability is severe, as it allows for complete compromise of user accounts without any prior authentication step. An attacker can log in as an administrator, gaining full control over the groupware instance, including access to emails, calendars, contacts, and shared resources belonging to all users. This leads to a total loss of confidentiality, integrity, and availability depending on the actions taken by the attacker. Sensitive corporate communications could be exfiltrated, calendar schedules revealed for social engineering purposes, or accounts used as pivot points for further network intrusion. The severity is amplified because it requires no user interaction such as clicking a link; it can be exploited via automated scripts sending crafted HTTP requests directly to the server endpoint.
This vulnerability aligns with CWE-287 Improper Authentication and CWE-306 Missing Authentication for Critical Function within the Common Weakness Enumeration framework. It also maps to ATT&CK technique T1078 Valid Accounts, specifically the sub-technique of using default or weak credentials if applicable, but more accurately reflects unauthorized access through authentication bypass mechanisms often categorized under initial access vectors where valid accounts are obtained without proper credential validation. The root cause is a configuration error rather than a code defect in SOGo itself, highlighting the importance of secure deployment practices for complex software stacks.
Mitigation strategies must focus on enforcing strict proxy hygiene and application-level verification. Administrators should immediately update to version 5.8.0~ynh9 or later, where this issue has been resolved by correcting the configuration defaults. In environments running older versions, a temporary workaround involves configuring Nginx to explicitly strip the x-webobjects-remote-user header before passing requests to SOGo using proxy_hide_header directives. Additionally, implementing strict access controls at the network level can limit exposure, though direct patching is the only reliable long-term solution. Regular audits of reverse proxy configurations are essential to ensure that sensitive headers intended for internal service communication are not inadvertently exposed to external clients, thereby maintaining the integrity of the authentication boundary between public-facing interfaces and backend application logic.