Eine an der ETH Zürich abgeschlossene Masterarbeit hat mehrere Schwachstellen im SEPPmail Secure E-Mail Gateway aufgezeigt. Das Thema ist deshalb relevant, weil solche Lösungen gerade dort eingesetzt werden, wo E-Mails verschlüsselt, signiert oder über geschützte Webmail-Funktionen ausgetauscht werden sollen.

SEPPmail hat die Befunde im Rahmen eines Responsible-Disclosure-Prozesses bearbeitet und mehrere Updates veröffentlicht. META10 hat den entsprechenden Hersteller-Patch umgehend eingespielt. Der Fall zeigt exemplarisch: Sicherheitsprodukte müssen nicht nur eingeführt, sondern auch laufend gepflegt, überwacht und aktualisiert werden.

Eine ETH-Arbeit mit praktischer Relevanz

Auf der Projektseite der Applied Cryptography Group der ETH Zürich ist die Masterarbeit «Breaking SEPPmail: A Case Study of Email Encryption in the Wild» von Andris Suter-Dörig als abgeschlossenes Projekt 2026 aufgeführt. Betreut wurde sie von Prof. Kenny Paterson und Matteo Scarlata. Ein öffentlich herunterladbarer PDF-Bericht ist dort derzeit nicht verlinkt.

Öffentlich nachvollziehbar wird der Inhalt deshalb vor allem über Herstellerinformationen, CVE-Einträge des Bundesamts für Cybersicherheit BACS sowie spätere Release Notes von SEPPmail. In der Revision History von SEPPmail werden mehrere Befunde ausdrücklich der ETH Zürich zugeordnet. Damit handelt es sich nicht um eine abstrakte akademische Analyse, sondern um eine Untersuchung mit direkter Auswirkung auf ein in der Praxis genutztes Sicherheitsprodukt.

Was die Analyse im Kern festgestellt hat

Die veröffentlichten Informationen zeigen ein klares Muster: Die Befunde betrafen vor allem jene Funktionen, auf denen das Vertrauen in eine sichere E-Mail-Kommunikation beruht. Dazu gehören die Verarbeitung von S/MIME und PGP, die Interpretation von E-Mail-Headern, die Prüfung von Signaturen und Zertifikaten, der Umgang mit Betreff-Tags sowie Funktionen rund um GINA-Webmail.

Vereinfacht gesagt geht es um die Frage, ob ein System korrekt erkennt, wer eine Nachricht signiert hat, ob eine verschlüsselte Nachricht tatsächlich richtig behandelt wird und ob manipulierte Inhalte zuverlässig abgefangen werden. Gerade bei verschlüsselter E-Mail ist dies zentral. Wenn Signaturen, Header oder Entschlüsselungsprozesse falsch interpretiert werden, kann dies die Vertrauensbasis der Kommunikation schwächen.

Das Bundesamt für Cybersicherheit BACS führt mehrere SEPPmail-Schwachstellen in seiner CVE-Datenbank. Dazu gehören unter anderem kritische und hoch eingestufte Schwachstellen im Zusammenhang mit PDF-Passwörtern, ZIP-Anhängen, Header-Verarbeitung sowie S/MIME- und PGP-Funktionen.

Warum GINA, Anhänge und Webmail-Funktionen besonders sensibel sind

Ein zweiter Bereich betrifft Webmail- und Austauschfunktionen. GINA wird genutzt, um verschlüsselte Kommunikation mit externen Empfängerinnen und Empfängern zu ermöglichen, auch wenn diese nicht über dieselbe technische Infrastruktur verfügen. Solche Portalfunktionen sind nützlich, erhöhen aber auch die Anforderungen an Zugriffsschutz, Sitzungslogik, Trennung von Domains und saubere Verarbeitung von Inhalten.

In späteren Release Notes nennt SEPPmail weitere von der ETH Zürich gefundene und behobene Schwachstellen. Für Unternehmen ist daran weniger der einzelne technische Name entscheidend, sondern die betriebliche Konsequenz: Wo Webmail-Zugriffe, externe Empfängerinnen und Empfänger, verschlüsselte Inhalte und Anhänge zusammenkommen, müssen Sicherheitsprüfungen besonders robust sein.

Auch das Attachment-Handling ist sicherheitskritisch. Anhänge, ZIP-Dateien, Uploads und Large-File-Transfer-Funktionen sind im Alltag selbstverständlich, gehören aber zu den klassischen Bereichen, in denen fehlerhafte Pfadprüfung, ungenügende Filterung oder unsichere Verarbeitung zu schwerwiegenden Folgen führen können.

Nicht jeder spätere Befund stammt direkt aus der ETH-Arbeit

Wichtig ist die saubere Einordnung: Nicht alle später diskutierten SEPPmail-Schwachstellen stammen direkt aus der ETH-Masterarbeit. InfoGuard beschreibt in einer eigenen Analyse, dass Hinweise auf ein ETH-Forschungsprojekt ein Anlass waren, weitere Komponenten von SEPPmail vertieft zu prüfen. Dabei wurden zusätzliche kritische Schwachstellen gefunden, unter anderem in GINA V2 und im Large-File-Transfer-Bereich.

Auch SEPPmail unterscheidet in den eigenen Release Notes zwischen Befunden der ETH Zürich und mehreren von InfoGuard gefundenen Schwachstellen. In Version 15.0.4 wurden gemäss Hersteller sowohl weitere ETH-Befunde als auch mehrere InfoGuard-Funde behoben. Diese Unterscheidung ist wichtig, weil sie zeigt: Die ETH-Arbeit war ein wesentlicher Auslöser und deckte strukturell relevante Schwächen auf. Die spätere Sicherheitsdiskussion um SEPPmail wurde jedoch durch zusätzliche Analysen weiterer Fachpersonen erweitert.

Patch-Management als entscheidender Faktor

Für Betreiberinnen und Betreiber solcher Systeme ist die wichtigste Erkenntnis nicht die einzelne CVE-Nummer. Entscheidend ist, dass auch Sicherheitsprodukte selbst Teil der Angriffsfläche sind. Ein E-Mail-Gateway, das Verschlüsselung, Signaturen, Webmail-Zugriffe und Anhänge verarbeitet, befindet sich an einer besonders exponierten Stelle der Unternehmenskommunikation.

SEPPmail informierte über mehrere Appliance-Releases und verweist in den Information Notices auf sicherheitsrelevante Updates. Aus betrieblicher Sicht heisst das: Ein einmaliger Patch reicht bei solchen Lagen häufig nicht aus. Relevant ist, ob die gesamte Update-Kette nachvollzogen und vollständig eingespielt wurde.

META10 hat den entsprechenden Hersteller-Patch umgehend eingespielt. Gerade bei datensensitiven Schweizer Klein- und Mittelunternehmen KMU ist entscheidend, dass Sicherheitskomponenten nicht nur beschafft, sondern professionell betrieben werden. Dazu gehören Patch-Management, Monitoring, klare Betriebsverantwortung und eine nüchterne Einschätzung, welche Funktionen im eigenen Umfeld tatsächlich genutzt werden.

Damit wird deutlich: Die ETH-Analyse zu SEPPmail ist kein Grund für pauschale Verunsicherung, aber ein ernstzunehmender Hinweis auf die Realität moderner Cybersecurity. Vertrauen entsteht nicht allein durch Verschlüsselung oder ein Sicherheitslabel. Vertrauen entsteht durch geprüfte Prozesse, rasche Updates, transparente Kommunikation und einen Betrieb, der Sicherheitsmeldungen konsequent in konkrete Massnahmen übersetzt.