Bulwark Webmail: Zwei Routen praegen Identitaetscookies ohne Pruefung

Zwei Endpunkte stellen die verschluesselten Identitaetscookies fuer einen frei gewaehlten Benutzernamen aus, ohne die Angabe gegen den Mailserver zu pruefen

Advisory-ID: TP-2026-100
Produkt: Bulwark Webmail (Weboberflaeche fuer den Mailserver Stalwart, Next.js)
Schwachstellentyp: Fehlerhafte Authentifizierung (CWE-287)
CVE: beantragt am 19. September 2026 (GitHub CNA), Vergabe ausstehend
CVSS 3.1: 8.2 (Hoch) · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N
Betroffene Versionen: <= 1.9.2
Hersteller-Advisory: GHSA-wxcm-j4jc-9fxq
Behoben in: 1.10.0
Gemeldet: 16. September 2026

Zusammenfassung

Bulwark Webmail legt die Identitaet eines angemeldeten Nutzers in zwei serverseitig verschluesselten Cookies ab. Zwei Endpunkte stellen diese Cookies fuer einen Benutzernamen aus, den der Aufrufer selbst benennt, und pruefen die Angabe nicht gegen den Mailserver. Entspricht die uebergebene Serveradresse dem eingerichteten JMAP-Server, was der Normalfall ist, nehmen beide Routen den Zweig fuer vertrauenswuerdige Server und ueberspringen die Pruefung der Zugangsdaten vollstaendig. Das so entstandene Cookie ist kryptografisch gueltig, weshalb die nachgelagerte Pruefung es annimmt. Ein Angreifer ohne Konto auf der Instanz und ohne Konto auf dem Mailserver liest, ueberschreibt und loescht damit die synchronisierten Einstellungen jedes Nutzers.

Ursache

Die Endpunkte POST /api/auth/stalwart-context und POST /api/auth/session stellen die Identitaetscookies fuer den uebergebenen Benutzernamen aus und rufen verifyJmapAuth() nicht auf, sobald die uebergebene Serveradresse dem eingerichteten JMAP-Server entspricht. Die Pruefroutine verifyIdentity() vergleicht allein den Benutzernamen im entschluesselten Cookie mit dem angefragten Konto und prueft die darin enthaltenen Zugangsdaten nie erneut. Beides zusammen ergibt eine geschlossene Kette: die eine Seite stellt ein gueltiges Cookie ohne Nachweis aus, die andere nimmt jedes gueltige Cookie als Nachweis. Das ist eine Umgehung des Fixes fuer CVE-2026-34834, der die Rueckfallregel fuer Aufrufer ganz ohne Cookie entfernt hatte; diese Regel haelt weiterhin, denn ein Aufruf ohne Cookie wird abgewiesen. Die ausstellenden Routen liefern dem Angreifer lediglich das fehlende Cookie nach.

Proof of Concept

# Ohne Konto auf der Instanz und ohne Konto auf dem Mailserver:
POST /api/auth/session
{"username": "[email protected]", "serverUrl": "<eingerichteter JMAP-Server>"}

# Die Antwort setzt jmap_session und jmap_stalwart_ctx fuer das fremde Konto.
# Mit diesen Cookies die synchronisierten Einstellungen des Opfers lesen,
# ueberschreiben oder loeschen.

Das Lesen und Schreiben fremder Einstellungen setzt voraus, dass die Einstellungssynchronisation aktiv ist. Ueber die Umgebungsvariable ist sie ab Werk aus, der mitgelieferte Einrichtungsassistent schaltet sie jedoch ein, und die veroeffentlichte Abhilfe zu CVE-2026-34834 bestand gerade darin, sie abzuschalten. Das Praegen der Cookies selbst braucht keine abweichende Einstellung.

Auswirkung

  • Lesen, Ueberschreiben und Loeschen der synchronisierten Einstellungen jedes Nutzers durch einen Angreifer ohne jedes Konto.
  • Bestehen aller weiteren Anmeldeschranken des Produkts, die auf derselben Pruefroutine aufsetzen.
  • Kein Konto auf der Instanz und keines auf dem Mailserver noetig, der Angriff beginnt vollstaendig anonym.
  • Umgehung eines bereits veroeffentlichten Fixes, weshalb Betreiber die Luecke als geschlossen ansahen.

Referenzen

Steckt so etwas in Ihrer Software?

Diese Schwachstelle hat unser Team im Rahmen seiner Arbeit gefunden. Lassen Sie Ihre Anwendungen von denselben Spezialisten prüfen, mit einem Penetrationstest von turingpoint.

Pentest anfragen