SOGo Groupware Proxy Authentication Flaw Allows Unauthenticated Account Impersonation via WebObjects Header (CVE-2026-74864)

A critical authentication bypass vulnerability has been disclosed in SOGo, the open-source enterprise groupware server widely utilized for corporate webmail, CalDAV calendaring, and CardDAV contact synchronization. Discovered and analyzed by CERT Polska, cataloged as CVE-2026-74864, and published under GitHub Advisory GHSA-fxx9-8vhm-fwhc with a maximum CVSS v3.1 rating of 9.8 (Critical), the security flaw allows unauthenticated remote adversaries to bypass all password verification and gain total administrative access to any enterprise mailbox by injecting a crafted HTTP proxy header.

Reverse Proxy Single Sign-On (SSO) in SOGo Deployments

In modern enterprise email architectures, SOGo operates behind a reverse proxy (such as Nginx, Apache HTTPd, or HAProxy) that handles SSL termination, rate limiting, and web traffic routing. When organizations implement external Single Sign-On (such as Kerberos, OAuth, or SAML), SOGo can be configured to delegate authentication to the proxy using the configuration directive SOGoTrustProxyAuthentication = YES.

Under this model, the reverse proxy is expected to authenticate the user and transmit the verified username to SOGo via the internal FastCGI/HTTP header x-webobjects-remote-user.

Vulnerability Mechanics: Missing Ingress Header Scrubbing (CWE-287)

The vulnerability emerges from a synchronization breakdown between the reverse proxy configuration and SOGo's backend trust model. When SOGoTrustProxyAuthentication is enabled, SOGo unconditionally trusts the value of x-webobjects-remote-user:

# Attacker Exploitation Request submitted directly to Nginx Proxy
GET /SOGo/so/admin@enterprise.internal/Mail HTTP/1.1
Host: mail.enterprise.internal
# Malicious Header Injected by Attacker:
x-webobjects-remote-user: admin@enterprise.internal
Connection: close

In affected distribution packages (such as YunoHost sogo_ynh before 5.8.0~ynh9 and standard Nginx template implementations), the Nginx configuration failed to sanitize or strip x-webobjects-remote-user from incoming external client requests:

# Vulnerable Nginx Reverse Proxy Block
location ^~ /SOGo {
    proxy_pass http://127.0.0.1:20000;
    # DEFECT: proxy_set_header did NOT overwrite or clear x-webobjects-remote-user!
    # Nginx blindly forwards client-supplied header to SOGo daemon!
}

Because Nginx forwarded the client's header unmodified to the SOGo service running on localhost:20000, SOGo assumed that the front-end proxy had already validated the user's credentials. The application immediately established a fully authenticated session for admin@enterprise.internal without asking for a password or executing multi-factor authentication (MFA).

Attack Escalation and Compromise Matrix

Remediation & Defense Actions

1. Update SOGo Packages: Upgrade to version 5.8.0~ynh9 or apply the latest distribution packages provided by your operating system vendor.
2. Sanitize Proxy Headers in Nginx: Immediately inspect your Nginx reverse proxy configuration. Explicitly clear or overwrite the proxy authentication header before forwarding:

   # Remediated Nginx Configuration Directive
   location ^~ /SOGo {
       # Explicitly clear client-supplied proxy user header
       proxy_set_header x-webobjects-remote-user "";
       proxy_pass http://127.0.0.1:20000;
   }

3. Disable Trust Proxy Authentication if Unused: If single sign-on via reverse proxy is not required, ensure SOGoTrustProxyAuthentication = NO in /etc/sogo/sogo.conf.