Bulwark Webmail: Lesebestaetigung verschickt Mail mit fremder Absenderangabe

Ein Betreff mit Zeilenumbruch wird unveraendert in die Kopfzeilen der Lesebestaetigung uebernommen, die das Opfer selbst verschickt

Advisory-ID: TP-2026-102
Produkt: Bulwark Webmail (Weboberflaeche fuer den Mailserver Stalwart, Next.js)
Schwachstellentyp: Header-Injektion ueber CRLF (CWE-93)
CVE: beantragt am 19. September 2026 (GitHub CNA), Vergabe ausstehend
CVSS 3.1: 5.7 (Mittel) · CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:N
Betroffene Versionen: >= 1.7.3, <= 1.9.2
Hersteller-Advisory: GHSA-w38p-hpqv-g89c
Behoben in: 1.10.0
Gemeldet: 16. September 2026

Zusammenfassung

Bulwark baut die Lesebestaetigung Zeichen fuer Zeichen selbst zusammen und setzt den Betreff der Ausgangsnachricht in die Betreffzeile ein. Die Funktion, die Kopfzeilen kodiert, wird nur taetig, wenn der Wert ein Zeichen ausserhalb des ASCII-Bereichs enthaelt. Wagenruecklauf und Zeilenvorschub liegen innerhalb dieses Bereichs, weshalb ein Betreff mit eingebettetem Zeilenumbruch unveraendert durchgereicht wird. Der Mailserver dekodiert den Betreff, bevor der Klient ihn sieht, sodass ein Absender den Umbruch in einem kodierten Wort an der SMTP-Pruefung vorbeischmuggelt. Antwortet das Opfer auf die Bitte um eine Lesebestaetigung, werden die eingeschleusten Zeilen zu echten Kopfzeilen und einem echten Rumpf in einer Nachricht, die das Konto des Opfers verfasst, ablegt und versendet.

Ursache

encodeHeaderWord() kodiert einen Kopfzeilenwert nach RFC 2047 nur dann, wenn er ein Zeichen ausserhalb von ASCII enthaelt, und gibt ihn andernfalls unveraendert zurueck (lib/mdn.ts:65). Wagenruecklauf und Zeilenvorschub sind ASCII-Zeichen, weshalb ein Betreff mit bereits enthaltenem Umbruch diese Pruefung passiert und woertlich in die Betreffzeile der zusammengebauten Nachricht wandert. Der Mailserver Stalwart dekodiert den Betreff nach RFC 2047, bevor der Klient ihn erhaelt, sodass der Umbruch als base64-kodiertes Wort an SMTP vorbeikommt und dekodiert im Feld fuer den Betreff ankommt. Die Abfrage des Mailservers liefert die zuletzt gesetzte Absenderzeile, und der eingeschleuste Block steht hinter der echten, weshalb der Absender auch die sichtbare Absenderidentitaet bestimmt. Die Lesebestaetigung wird vom Konto des Opfers verfasst, im Ordner der gesendeten Nachrichten abgelegt und ueber dessen beglaubigte Einlieferung verschickt.

Proof of Concept

# Betreff der Ausgangsmail, als kodiertes Wort eingeliefert,
# damit der Zeilenumbruch an SMTP vorbeikommt:
Subject: =?utf-8?B?<base64 von: Hallo\r\nFrom: [email protected]\r\n...>?=

# Stalwart dekodiert den Betreff, der Umbruch erreicht den Klienten.
# Das Opfer bestaetigt die Lesebestaetigung -> die eingeschleusten Zeilen
# werden zu echten Kopfzeilen und einem echten Rumpf in einer Nachricht,
# die das Konto des Opfers verfasst und versendet.

Die Einstellung fuer Lesebestaetigungen muss beim Opfer auf Nachfragen stehen, was der Voreinstellung entspricht, oder auf immer; die Einstellung nie ist nicht betroffen. Die Nachricht muss zudem in einem anderen Ordner als Spam, Gesendet, Entwuerfe oder Papierkorb landen, da der Hinweis nur dort erscheint.

Auswirkung

  • Versand einer Nachricht mit frei gewaehlter Absenderangabe, Antwortadresse und HTML-Rumpf aus dem Postfach des Opfers.
  • Einlieferung ueber die beglaubigte Verbindung des Opfers, weshalb die Nachricht alle Pruefungen der Absenderdomaene besteht.
  • Ablage der gefaelschten Nachricht im Ordner der gesendeten Nachrichten des Opfers, womit sie auch im Nachhinein echt aussieht.
  • Eignung fuer gezielte Betrugsversuche, da Empfaenger eine Nachricht aus einem bekannten, legitimen Postfach erhalten.

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