Bulwark Webmail: The Editor Token Also Counts as a Full Session

The WOPI token and the session cookie are the same encrypted envelope under the same key, and the reader checks neither purpose nor scope

Advisory ID: TP-2026-105
Product: Bulwark Webmail (web interface for the Stalwart mail server, Next.js)
Vulnerability type: Insufficient verification of data authenticity (CWE-345)
CVE: requested on 19 September 2026 (GitHub CNA), assignment pending
CVSS 3.1: 7.3 (High) · CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N
Affected versions: main nach 1.9.2, unveroeffentlicht
Vendor advisory: GHSA-cqqx-mjcf-mh55
Fixed in: 1.10.0
Reported: 16 September 2026

Summary

For editing office documents, Bulwark hands the editor an access token. That token and the webmail session cookie are the same AES-256-GCM envelope under the same key derived from the session secret. The token carries a purpose tag, a scope limited to exactly one file and an expiry; the cookie reader checks none of those three fields and instead accepts any decrypted payload holding three string fields. An editor token presented as the session cookie is therefore accepted as a full session context and reaches the JMAP passthrough as well as the WebDAV and CalDAV routes. The editor itself never sees the cleartext password, so whoever holds the token wields the user's credentials without learning them.

Root cause

The editor token is minted as encryptPayload({ v: 1, t: 'wopi', ...payload, exp }) and therefore uses the same envelope and the same key as the session cookie (lib/wopi/token.ts:44-48 and lib/stalwart/auth-context.ts:58). The check isValidContext settles for a decrypted payload holding three string fields and looks at neither the purpose tag t: 'wopi', nor the single-file scope, nor the expiry. On the cookie path both of the token's limits therefore fall away, that is its binding to one file and its six-hour validity. The reverse direction is gated correctly, so the confusion runs one way only. The flaw arrived with the commit that introduced office editing in the files area and affects no released version.

Proof of Concept

# precondition: a configured office editor (wopiClientUrl).
# a party that gets to see the WOPI access token, such as the editor
# service itself or anyone observing it on that path, presents it as
# the session cookie:

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

# the reader checks neither t: 'wopi' nor the file scope nor exp
# -> full access to the user's mailbox, calendars and files, even
#    after the token has expired for its intended purpose.

Only the development state after 1.9.2 is affected; no released version carries the flaw. It requires a configured office editor, whose address is empty by default.

Impact

  • Reading and modifying the user's entire mailbox, calendars and files by any party that gets to see the editor token.
  • Loss of the file scope, so the token no longer concerns only the one document that was opened.
  • Continued use after the six hours have passed, since the expiry is not checked on this path.
  • Wielding the user's credentials without knowing them, as the password stays inside the encrypted envelope.

References

Is Something Like This in Your Software?

Our team found this vulnerability in the course of its work. Have your applications tested by the same specialists, with a penetration test from turingpoint.

Request a Pentest