Ein Sicherheitsupdate ist noch kein Schutz. Es ist zunächst eine veröffentlichte Korrektur. Zwischen dem Commit eines Projekts und dem laufenden Dienst liegen Paketierung, Distribution, App-Verwaltung, Installation und Kontrolle. Bei Roundcube lässt sich diese Kette gerade ungewöhnlich gut beobachten: Upstream veröffentlichte neue Versionen, Debian dokumentierte Backports und YunoHost aktualisierte sein App-Paket. Wer nur fragt „Welche Roundcube-Version ist aktuell?“, stellt deshalb die falsche Frage.

Die richtige Frage lautet: Welche korrigierte Version gehört zu meinem Installationsweg, und ist sie auf meinem System tatsächlich angekommen?

Der Anlass: mehrere Fehler, unterschiedliche Voraussetzungen

Roundcube veröffentlichte am 9. August 2026 die Sicherheitsupdates 1.6.18 und 1.7.3 und empfahl die Aktualisierung produktiver Installationen. Debian veröffentlichte am 30. August DSA-6479-1 für Trixie. Die behobenen Probleme reichen von bedingter Remote-Code-Ausführung über IMAP-Befehlsinjektion und gespeichertes Cross-Site-Scripting bis zu Umgehungen von Schutzfiltern.

Diese Begriffe sind ernst. Sie dürfen aber nicht zu einer pauschalen Katastrophenschlagzeile verklebt werden. Die Voraussetzungen unterscheiden sich.

• CVE-2026-74997 betrifft laut Debian Installationen, die das Plugin markasjunk mit dem Treiber cmd_learn verwenden. Der öffentliche Fix ändert die Ersetzung bereits shell-maskierter Platzhalterwerte.
• CVE-2026-75002 betrifft eine fehlerhafte Längensynchronisation bei der Mail-Suche, die IMAP-Befehlsinjektion ermöglichen konnte. Der Fix entfernt Wagenrücklauf und Zeilenumbruch aus dem Suchtext.
• CVE-2026-75004 betrifft die Umgehung deaktivierter Sieve-Aktionen und setzt das Plugin managesieve voraus.
• CVE-2026-74999 betrifft gespeichertes Cross-Site-Scripting bei „Add to address book“. Der Fix maskiert die ausgegebene Fehlermeldung.
• CVE-2026-75000 betrifft eine unzureichend bereinigte SVG-animate-Eigenschaft, durch die die Sperre externer Bilder umgangen werden konnte.

Belegt sind die Fehler, die konkreten Codeänderungen und die von Debian dokumentierten Paketstände. Nicht belegt sind in der zugrunde liegenden Recherche eine aktive Ausnutzung im großen Stil, eine vollständige Exploit-Kette für alle Fehler oder die Verbreitung der optionalen Plugins. Diese Grenzen sind Teil des Befunds, nicht dessen Relativierung.

Upstream: Die neue Versionsnummer ist nur ein Weg

Für direkte Installationen aus den Projektquellen sind Roundcube 1.6.18 und 1.7.3 die korrigierten Linien. Wer diesen Weg gewählt hat, muss Projektmeldungen, Release Notes und Folgecommits beobachten. Am 10. August folgte beispielsweise eine Korrektur gegen eine PHP-Warnung im geänderten cmd_learn-Treiber. Daraus darf keine fortbestehende Codeausführungslücke erfunden werden; dokumentiert ist eine Funktionskorrektur.

Der Upstream-Weg wirkt auf den ersten Blick einfach: neue Version laden, installieren, fertig. Im Betrieb ist er es nicht. Eine manuelle Installation braucht einen dokumentierten Updateprozess, Integritätsprüfung, Sicherung und einen Rückweg. Wer eigentlich ein Distributions- oder App-Paket nutzt und dann Dateien aus einem Upstream-Archiv darüberkopiert, verlässt womöglich den gepflegten Paketweg. Das kann die nächste Aktualisierung schwerer statt leichter machen.

Debian: Eine kleinere Grundversion kann trotzdem korrigiert sein

Debian nennt für Trixie 1.6.18+dfsg-0+deb13u1 als korrigierte Version. Für Bookworm dokumentiert der Security Tracker 1.6.5+dfsg-1+deb12u11, für Bullseye 1.4.15+dfsg.1-1+deb11u11.

Gerade die letzten beiden Zahlen zeigen, warum ein nackter Vergleich mit Upstream in die Irre führt. Stabile Distributionen übernehmen Sicherheitskorrekturen häufig als Backport. Sie behalten die ältere Grundversion bei und integrieren die relevanten Patches. Das reduziert unnötige Funktionssprünge und schützt die Stabilität des Systems.

Die faire Gegenposition lautet deshalb: Ein zeitversetztes Advisory und eine niedrigere Upstream-Grundversion sind nicht automatisch ein Versagen. Qualitätssicherung und distributionsgerechte Integration brauchen Zeit. Zwischen dem Roundcube-Release am 9. August und Debian DSA-6479-1 am 30. August lagen 21 Kalendertage. Diese Differenz ist belegt. Warum sie genau so lang war, ist es nicht.

Für Betreiber folgt daraus: Nicht 1.6.5 gegen 1.6.18 halten und Alarm schlagen. Den vollständigen Debian-Versionsstring lesen, den Security Tracker prüfen und den Paketstatus des eigenen Systems feststellen. Wer aus Angst fremde Pakete in eine stabile Installation kippt, kann eine bereits gepflegte Kette durch eine private Sonderkonstruktion ersetzen.

YunoHost: Ein aktueller Katalog ist noch kein aktueller Server

Das öffentliche Manifest und der App-Katalog von YunoHost wiesen am 1. September 1.7.3~ynh1 aus. Der Upgradecommit wurde am 10. August in das öffentliche App-Repository übernommen. Das zeigt, dass ein aktuelles App-Paket bereitsteht.

Es zeigt nicht, dass ein bestimmter Server es bereits installiert hat. Ein Katalogeintrag ist ein Angebot, kein Zustandsnachweis. Wer Roundcube als YunoHost-App betreibt, muss den lokalen App-Stand prüfen und den vorgesehenen App-Upgradepfad benutzen. Eine manuelle Überlagerung mit einem Upstream-Tarball würde aus einer nachvollziehbaren App-Installation eine Mischform machen.

Auch hier gilt: Der Paketweg ist Teil der Sicherheitsarchitektur. Er bestimmt, woher Updates kommen, welche Anpassungen enthalten sind, wie Migrationen laufen und welcher Rückweg unterstützt wird.

Die Betreibercheckliste: erst feststellen, dann ändern

Vor jedem Eingriff sollten fünf Punkte geklärt sein:

1. Installationsweg: Upstream, Debian-Paket, YunoHost-App oder etwas anderes?
2. Vollständige Version: Nicht nur die sichtbare Grundversion, sondern der gesamte Paket- oder App-String.
3. Aktive Komponenten: Sind markasjunk, cmd_learn, managesieve oder andere optionale Plugins aktiv?
4. Sicherung: Sind Konfiguration, Datenbank und relevante Betriebsdaten erfasst?
5. Rückweg und Test: Wie wird zurückgerollt, und welche Funktionen werden nach dem Update geprüft?

Ein universeller Upgradebefehl wäre hier unseriös. Was auf Debian richtig ist, kann auf YunoHost den App-Pfad umgehen. Was für eine manuelle Installation passt, kann von der Distribution nicht mehr verwaltet werden.

Nach einer Aktualisierung reicht eine erreichbare Login-Seite nicht. Zu prüfen sind mindestens Anmeldung, IMAP-Zugriff, Versand, Kontakte und die tatsächlich verwendeten Plugins. Hinzu kommen Webserver-, PHP- und App-Protokolle. Ein HTTP-Status 200 sagt nicht, ob die Filterverwaltung arbeitet oder Kontakte korrekt gespeichert werden.

Bewertung: Souveränität ist die beherrschte Lieferkette

Eigene Meinung / redaktionelle Bewertung: Ein eigener Mailserver ohne geklärte Patch- und Paketkette ist noch keine digitale Souveränität. Er ist Verantwortung ohne Überblick. Wer nur einen Server bezahlt, aber Herkunft, Wartung und Rückweg seiner Software nicht kennt, besitzt Hardwarezugriff – noch keine belastbare Handlungsfähigkeit.

Das ist kein Argument für die Flucht zum Hyperscaler. Im Gegenteil. Die Roundcube-Korrekturen sind öffentlich. Debian-Backports sind dokumentiert. Das YunoHost-Manifest ist einsehbar. Diese Prüfbarkeit ist ein politischer und praktischer Vorteil freier Infrastruktur. Bei einem geschlossenen Dienst bleibt häufig nur die Behauptung des Anbieters, das Problem sei behoben.

Offenheit verteilt jedoch Verantwortung. Upstream korrigiert Code. Distributionen und App-Projekte integrieren ihn. Betreiber müssen feststellen, installieren und verifizieren. Eine Community braucht deshalb nicht nur Adminwissen, sondern übergabefähige Dokumentation: Paketquelle, Zuständigkeit, Prüfdatum, Sicherungsweg und eine geheimnisfreie Betriebsnotiz. Tokens, private Adressen und interne Konfigurationen gehören dort selbstverständlich nicht hinein.

Die scharfe, aber faire Schlussfolgerung lautet: Souveränität ist nicht, alles allein zu machen. Souveränität ist, Abhängigkeiten sehen, prüfen und wechseln zu können.

Fazit

Roundcube hat Sicherheitsupdates veröffentlicht. Debian hat korrigierte Paketstände für Trixie, Bookworm und Bullseye dokumentiert. YunoHost stellt öffentlich ein aktualisiertes App-Paket bereit. Das sind belastbare Tatsachen.

Ob ein konkreter Server geschützt ist, lässt sich daraus nicht ableiten. Dafür braucht es den Installationsweg, den vollständigen lokalen Versionsstand, die Plugin-Konfiguration, eine Sicherung und Funktionsprüfungen nach dem Update. Für einen Darknight-Coffee-Produktivhost wurde diese Prüfung in der zugrunde liegenden Recherche ausdrücklich nicht durchgeführt.

Die vernünftige Reaktion ist deshalb weder Panik noch Entwarnung. Sie ist eine ruhige Nachweiskette vom Projektcommit bis zum funktionierenden eigenen Dienst.

Quellen

1. Debian Security Information, DSA-6479-1, 30. August 2026: https://www.debian.org/security/
2. Debian Security Tracker, DSA-6479-1: https://security-tracker.debian.org/tracker/DSA-6479-1
3. Debian Security Tracker, Roundcube-Quellpaket: https://security-tracker.debian.org/tracker/source-package/roundcube
4. Debian Security Tracker, DLA-4760-1: https://security-tracker.debian.org/tracker/DLA-4760-1
5. Debian Security Tracker, CVE-2026-74997: https://security-tracker.debian.org/tracker/CVE-2026-74997
6. Debian Security Tracker, CVE-2026-75002: https://security-tracker.debian.org/tracker/CVE-2026-75002
7. Debian Security Tracker, CVE-2026-75004: https://security-tracker.debian.org/tracker/CVE-2026-75004
8. Debian Security Tracker, CVE-2026-74999: https://security-tracker.debian.org/tracker/CVE-2026-74999
9. Debian Security Tracker, CVE-2026-75000: https://security-tracker.debian.org/tracker/CVE-2026-75000
10. Roundcube, „Security updates 1.6.18 and 1.7.3 released“, 9. August 2026: https://roundcube.net/news/2026/08/09/security-updates-1.6.18-and-1.7.3
11. Roundcube, Release 1.6.18: https://github.com/roundcube/roundcubemail/releases/tag/1.6.18
12. Roundcube, RCE-Fixcommit: https://github.com/roundcube/roundcubemail/commit/b8f90e28a46d42e79a69568cba897f8f4223d9cd
13. Roundcube, IMAP-Injection-Fixcommit: https://github.com/roundcube/roundcubemail/commit/73233abe581b3b31cefd00041c7086c40e1793ea
14. Roundcube, Stored-XSS-Fixcommit: https://github.com/roundcube/roundcubemail/commit/32f20c6bfd12dff9cfb6880ae303e740f0804fe8
15. Roundcube, 1.6-Folgecommit: https://github.com/roundcube/roundcubemail/commit/495d211638f222336b20f4744545c53712426c2a
16. YunoHost Roundcube-App, Manifest: https://raw.githubusercontent.com/YunoHost-Apps/roundcube_ynh/master/manifest.toml
17. YunoHost Roundcube-App, Upgradecommit: https://github.com/YunoHost-Apps/roundcube_ynh/commit/7db2a9afdaf3beda55ef51c6cba3d452cdb4a7be
18. YunoHost App-Katalog, Roundcube: https://apps.yunohost.org/app/roundcube

Transparenz und Prüfstatus

• Quellenbasis: offizielle Projekt-, Debian-, CVE-/Tracker-, Commit- und YunoHost-Quellen.
• Keine eigene Prüfung eines Produktivhosts, keine erfundene Betriebserfahrung.
• Redaktioneller Entwurf mit Crow/Codex auf Basis des GPT-5-Modells; persönliche Endredaktion und Veröffentlichungsverantwortung liegen bei Andreas.
• Zeitabhängige Paketstände müssen unmittelbar vor Veröffentlichung erneut geprüft werden.

CTA

Diskussion: https://treff.darknight-coffee.eu/@carrabelloy
Podcast: https://podcast.darknight-coffee.org/pages/startseite
Blog: https://carrabelloy.darknight-coffee.org/blog/

Wenn dir das Projekt hilft: Spendenlinks sind im Blog.