Kurzfassung

Die Schwachstellen CVE-2026-74865 und CVE-2026-74864 betreffen die Paketierung sogo_yhn für SOGo und ermöglichen unter bestimmten Einstellungen die Anmeldung an fremden Konten ohne korrektes Passwort. Besonders schwer wiegt CVE-2026-74864 mit CVSS 9.3, kritisch; CVE-2026-74865 ist ebenfalls kritisch mit CVSS 9.2. Behoben sind beide Probleme in Version 5.8.0~ynh9.

Was ist passiert?

Die Schwachstelle entsteht durch eine fehlerhafte Konfiguration von SOGo in sogo_yhn. Dort wird der Parameter SOGoTrustProxyAuthentication=YES gesetzt. In dieser Konstellation lässt sich die Passwortprüfung bei der HTTP-Basic-Authentifizierung umgehen.

Neu hinzugekommen ist mit CVE-2026-74864 eine weitere kritische Schwachstelle in derselben Paketierung: sogo_yhn konfiguriert SOGo so, dass Anfragen mit dem HTTP-Header x-webobjects-remote-user als von einem verifizierten Benutzer stammend behandelt werden. Da Nginx diesen Header nicht entfernt, kann ein Client ihn selbst setzen und sich dadurch ohne Passwort als beliebiger Benutzer ausgeben – ausdrücklich auch als privilegierter Benutzer.

Ein Angreifer benötigt laut den bekannten technischen Angaben weder ein bestehendes Konto noch eine Interaktion durch den Nutzer. Wenn der Benutzername eines vorhandenen Kontos bekannt ist, reicht bei CVE-2026-74865 offenbar ein beliebiges Passwort aus, um sich erfolgreich an diesem Konto anzumelden. Bei CVE-2026-74864 ist laut NVD nicht einmal eine Passwortprüfung erforderlich, wenn der manipulierte Header akzeptiert wird.

Für Unternehmen im DACH-Raum ist das vor allem dann relevant, wenn SOGo über das Internet erreichbar ist oder wenn Dritte auf den Webzugang zugreifen können. Da SOGo oft für E-Mail, Kalender und Kontakte eingesetzt wird, kann eine erfolgreiche Anmeldung unmittelbar sensible Kommunikationsdaten offenlegen.

Technische Details

Die Kennung CVE-2026-74865 beschreibt eine fehlerhafte Vertrauensstellung gegenüber vorgeschalteter Authentifizierung. Durch die Konfiguration SOGoTrustProxyAuthentication=YES akzeptiert die Anwendung Anmeldedaten in einer Weise, die die eigentliche Passwortprüfung aushebelt.

CVE-2026-74864 beschreibt ein eng verwandtes, aber noch direkter ausnutzbares Problem: Anfragen mit dem Header x-webobjects-remote-user werden als bereits verifiziert behandelt, obwohl Nginx diesen Header nicht entfernt. Dadurch kann jeder Client den Header selbst mitsenden und sich gegenüber SOGo als beliebiger Benutzer ausgeben. Das betrifft nach der veröffentlichten Beschreibung auch privilegierte Konten.

Der Basiswert für CVE-2026-74865 beträgt CVSS 9.2 nach CVSS 4.0. Der Vektor beschreibt einen Angriff über das Netzwerk, ohne erforderliche Berechtigungen und ohne Nutzerinteraktion; die Angriffskomplexität ist zwar als hoch eingestuft, technisch kann also jeder externe Angreifer ansetzen, wenn die betroffene Instanz erreichbar ist und einen gültigen Benutzernamen kennt.

Für CVE-2026-74864 nennt der NVD sogar CVSS 9.3 nach CVSS 4.0. Der Vektor beschreibt ebenfalls einen Netzwerkangriff ohne Authentifizierung und ohne Nutzerinteraktion, hier jedoch bei geringer Angriffskomplexität. Das unterstreicht, dass die Header-basierte Vertrauensstellung in exponierten Umgebungen besonders kritisch ist.

Wichtig ist die Einordnung der Werte: CVSS beschreibt die technische Schwere einer Schwachstelle, nicht automatisch die tatsächliche Ausnutzung im Feld. Ob Angriffe bereits beobachtet wurden, geht aus den NVD-Einträgen nicht hervor.

Wer ist betroffen?

Betroffen sind Installationen von sogo_yhn, bei denen die fehlerhafte Konfiguration aktiv ist. Als behobene Fassung wird 5.8.0~ynh9 genannt. Daraus folgt: Frühere Versionen sollten als potenziell verwundbar behandelt werden.

Das gilt sowohl für CVE-2026-74865 als auch für CVE-2026-74864. Beide Schwachstellen werden für sogo_yhn beschrieben und beide sollen in Version 5.8.0~ynh9 behoben sein.

Nicht jede SOGo-Installation ist automatisch betroffen. Die Angaben beziehen sich ausdrücklich auf sogo_yhn und damit auf die betreffende Paketierung beziehungsweise Integrationsumgebung. Wer SOGo unabhängig davon betreibt, sollte dennoch die eigene Konfiguration prüfen, insbesondere den Umgang mit Proxy-Authentifizierung und die Behandlung vertrauenswürdiger Header wie x-webobjects-remote-user.

Empfohlene Maßnahmen

1. Sofort auf 5.8.0~ynh9 aktualisieren. Das ist die wichtigste Maßnahme, weil die Schwachstellen dort behoben wurden.

2. Exponierte Instanzen priorisieren. Systeme mit Internetzugang oder extern erreichbarer Weboberfläche sollten zuerst gepatcht werden.

3. Konfiguration prüfen. Kontrollieren Sie, ob SOGoTrustProxyAuthentication=YES gesetzt ist und ob diese Einstellung in Ihrer Umgebung überhaupt erforderlich ist.

4. Header-Vertrauen und Proxy-Verhalten überprüfen. Prüfen Sie insbesondere, ob Anfragen mit x-webobjects-remote-user an die Anwendung weitergereicht werden und ob vorgeschaltete Komponenten solche Header bereinigen oder nur aus klar definierten vertrauenswürdigen Quellen akzeptieren.

5. Anmeldeprotokolle auswerten. Suchen Sie nach erfolgreichen Logins mit ungewöhnlichen Mustern, insbesondere auf privilegierte oder viel genutzte Konten. Auffällig sind Anmeldungen ohne plausiblen zeitlichen oder geografischen Bezug.

6. Zugangsdaten sensibler Konten vorsorglich zurücksetzen. Wenn Ihre Instanz öffentlich erreichbar war und ein Missbrauch nicht sicher ausgeschlossen werden kann, sollten Sie Passwörter betroffener Benutzer ändern und bestehende Sitzungen ungültig machen.

7. Zusätzliche Schutzschichten aktivieren. Wo möglich, begrenzen Sie den Zugriff per Reverse Proxy, VPN, IP-Filter oder Single-Sign-on-Regeln, bis alle Systeme aktualisiert sind.

Einschätzung von CyberSecurity-News.de

Die technische Auswirkung ist erheblich: Wenn ein fremdes Konto allein mit Benutzername und beliebigem Passwort übernommen werden kann oder eine Anwendung sogar einen vom Client gesetzten Identitäts-Header ungeprüft akzeptiert, ist das für Mail- und Groupware-Systeme ein ernstes Risiko. Besonders kritisch ist das, weil solche Plattformen oft vertrauliche Kommunikation, Kontakte und Kalenderdaten zentral bündeln.

Mit CVE-2026-74864 verschärft sich die Lage zusätzlich. Im Vergleich zur bereits kritischen CVE-2026-74865 wirkt das neu dokumentierte Header-Problem noch direkter, weil laut NVD keine Passwortprüfung nötig ist und die Angriffskomplexität niedriger bewertet wird. Für Administratoren heißt das praktisch: öffentlich erreichbare Instanzen von sogo_yhn sollten mit höchster Priorität aktualisiert und auf verdächtige Zugriffe geprüft werden.

Die Informationslage ist dennoch nicht vollständig. Der NVD nennt die CVSS-Werte und die Grundursachen, liefert aber keine tieferen Angaben zu betroffenen Bereitstellungsszenarien, zu möglichen Indikatoren für Kompromittierungen oder zu beobachteter Ausnutzung. Für Administratoren ist die Lage trotzdem klar genug: Versionen vor 5.8.0~ynh9 gehören zügig aktualisiert und auf verdächtige Logins geprüft.

Für die meisten Leser ist das kein Massenproblem, weil es eine spezifische SOGo-Integration betrifft. Betroffene Organisationen sollten die Schwachstellen aber nicht aufschieben, denn die Missbrauchsszenarien sind direkt, nachvollziehbar und mit hohem Schadenspotenzial verbunden.

Fazit

Wer sogo_yhn mit SOGo betreibt, sollte CVE-2026-74865 und CVE-2026-74864 kurzfristig behandeln und auf 5.8.0~ynh9 aktualisieren. Prüfen Sie anschließend Konfiguration, Header-Vertrauen und Login-Protokolle, insbesondere bei öffentlich erreichbaren Instanzen.

Quellenangabe

Weiterführende technische Informationen bietet der NVD-Eintrag zu CVE-2026-74865.

Zusätzliche technische Informationen bietet der NVD-Eintrag zu CVE-2026-74864.