Bulwark Webmail: Editor-Token gilt auch als vollwertige Sitzung

Der WOPI-Token und das Sitzungscookie sind derselbe verschluesselte Umschlag unter demselben Schluessel, und der Leser prueft weder Zweck noch Geltungsbereich

Advisory-ID: TP-2026-105
Produkt: Bulwark Webmail (Weboberflaeche fuer den Mailserver Stalwart, Next.js)
Schwachstellentyp: Unzureichende Pruefung der Datenechtheit (CWE-345)
CVE: beantragt am 19. September 2026 (GitHub CNA), Vergabe ausstehend
CVSS 3.1: 7.3 (Hoch) · CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N
Betroffene Versionen: main nach 1.9.2, unveroeffentlicht
Hersteller-Advisory: GHSA-cqqx-mjcf-mh55
Behoben in: 1.10.0
Gemeldet: 16. September 2026

Zusammenfassung

Fuer die Bearbeitung von Office-Dokumenten uebergibt Bulwark dem Editor einen Zugriffstoken. Dieser Token und das Sitzungscookie der Webmail sind derselbe mit AES-256-GCM verschluesselte Umschlag unter demselben, aus dem Sitzungsgeheimnis abgeleiteten Schluessel. Der Token traegt eine Zweckmarke, einen Geltungsbereich auf genau eine Datei und ein Ablaufdatum; der Leser des Cookies prueft keines dieser drei Felder, sondern nimmt jeden entschluesselten Inhalt mit drei Zeichenkettenfeldern an. Ein Editor-Token, als Sitzungscookie vorgelegt, gilt daher als vollwertiger Sitzungskontext und erreicht den JMAP-Durchgriff sowie die WebDAV- und CalDAV-Routen. Der Editor selbst sieht das Passwort nie im Klartext, weshalb der Inhaber des Tokens die Zugangsdaten des Nutzers ausuebt, ohne sie zu kennen.

Ursache

Der Editor-Token wird als encryptPayload({ v: 1, t: 'wopi', ...payload, exp }) erzeugt und nutzt damit denselben Umschlag und denselben Schluessel, die auch das Sitzungscookie verwenden (lib/wopi/token.ts:44-48 und lib/stalwart/auth-context.ts:58). Die Pruefung isValidContext begnuegt sich mit einem entschluesselten Inhalt, der drei Zeichenkettenfelder traegt, und sieht sich weder die Zweckmarke t: 'wopi' noch den Geltungsbereich auf eine Datei noch das Ablaufdatum an. Beim Weg ueber das Cookie entfallen damit beide Begrenzungen des Tokens, also die Bindung an eine einzelne Datei und seine Gueltigkeit von sechs Stunden. Die umgekehrte Richtung ist richtig abgesichert, weshalb die Verwechslung nur in eine Richtung laeuft. Die Luecke entstand mit dem Commit, der die Office-Bearbeitung im Dateibereich eingefuehrt hat, und betrifft keine veroeffentlichte Fassung.

Proof of Concept

# Voraussetzung: ein eingerichteter Office-Editor (wopiClientUrl).
# Eine Partei, die den WOPI-Zugriffstoken zu sehen bekommt, etwa der
# Editor-Dienst selbst oder ein Mitlesender auf diesem Weg, legt ihn
# als Sitzungscookie vor:

curl https://webmail.example/api/jmap \
  -b "jmap_stalwart_ctx=<wopi-token>" ...

# Der Leser prueft weder t: 'wopi' noch den Dateibezug noch exp
# -> voller Zugriff auf Postfach, Kalender und Dateien des Nutzers,
#    auch nachdem der Token fuer seinen eigentlichen Zweck abgelaufen ist.

Betroffen ist allein der Entwicklungsstand nach 1.9.2; keine veroeffentlichte Fassung traegt den Fehler. Vorausgesetzt ist ein eingerichteter Office-Editor, dessen Adresse ab Werk leer ist.

Auswirkung

  • Lesen und Veraendern des gesamten Postfachs, der Kalender und der Dateien des Nutzers durch jede Partei, die den Editor-Token zu sehen bekommt.
  • Verlust des Dateibezugs, weshalb der Token nicht mehr nur das eine geoeffnete Dokument betrifft.
  • Weiterverwendung nach Ablauf der sechs Stunden, da das Ablaufdatum auf diesem Weg nicht geprueft wird.
  • Ausuebung der Zugangsdaten des Nutzers, ohne sie zu kennen, da das Passwort im verschluesselten Umschlag verbleibt.

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