Roundcube unter Angriff: Was KMU bei ihrem Webmail jetzt prüfen sollten

Eine aktualisierte Behördenwarnung zu Roundcube macht ungepatchte Webmail-Systeme zum Prüfauftrag. So klären KMU Betroffenheit, Updates und Zuständigkeiten.

Am 21. September 2026 hat das Canadian Centre for Cyber Security seine Warnung AV26-503 aktualisiert: Öffentlich zugängliche Berichte deuten demnach auf die aktive Ausnutzung von CVE-2026-48842 hin. Die Schwachstelle betrifft eine SQL-Injection vor der Anmeldung im Roundcube-Plugin virtuser_query. Der Patch ist nicht neu: Roundcube veröffentlichte die betreffenden Korrekturen bereits am 24. Mai. Neu in der vergangenen Woche ist die Behördenwarnung zur Ausnutzung. Für uns ist das ein besonders handlungsrelevantes Thema für deutsche KMU: Statt eine weitere Plattformankündigung zu bewerten, lässt sich hier unmittelbar klären, ob ein eigener oder eingekaufter Dienst überprüft werden muss. Dieser Beitrag trennt bestätigte Produktangaben, die begrenzte öffentliche Erkenntnislage und unsere Umsetzungsempfehlungen.

Quelle: Canadian Centre for Cyber Security, Roundcube-Sicherheitsupdate vom Mai, SOCRadar-Einordnung.

Quelle: Behördenwarnung AV26-503, Roundcube-Sicherheitsupdate vom September, Plugin-Dokumentation.

1. Was bekannt ist – und was die Warnung nicht belegt

Roundcube beschreibt den Fehler als Umgehung einer Backslash-Escaping-Behandlung bei preg_replace, die eine SQL-Injection vor der Authentifizierung ermöglicht. Der Debian Security Tracker ordnet CVE-2026-48842 den Upstream-Reihen 1.6.x vor 1.6.16 und 1.7.x vor 1.7.1 zu. Die Behördenmeldung vom September ergänzt den Hinweis auf Ausnutzung anhand öffentlicher Berichte, veröffentlicht aber keine eigene technische Kampagnenanalyse. Daraus machen wir weder eine Behauptung über eine flächendeckende Angriffswelle noch über betroffene deutsche Unternehmen. Ebenso wäre es falsch, die Mai-Korrektur als neuen September-Patch darzustellen. Für die betriebliche Entscheidung reicht die belegte Kombination dennoch aus: Ein bekannter Fehler besitzt eine verfügbare Korrektur, und eine Behörde warnt nun vor berichteter Ausnutzung. Die eigene Exposition sollte deshalb zeitnah statt beim nächsten beliebigen Wartungstermin bewertet werden.

Quelle: Roundcube: ursprüngliche Korrektur, Debian Security Tracker, Canadian Centre for Cyber Security.

2. Das Plugin entscheidet mit über die Betroffenheit

Laut Roundcube-Dokumentation übernimmt virtuser_query datenbankgestützte Zuordnungen zwischen Benutzernamen und E-Mail-Adressen. Plugins werden nicht allein durch das Vorhandensein ihres Verzeichnisses geladen: Sie müssen in der Konfigurationsoption plugins aktiviert sein. In der dokumentierten Standardkonfiguration geschieht dies über config/config.inc.php. Unsere Empfehlung ist, den tatsächlich wirksamen Zustand zu prüfen und nicht nur eine zufällig gefundene Konfigurationsdatei. Gerade bei einem betreuten Hostingangebot sollte der Betreiber bestätigen, welche Konfiguration die laufende Anwendung nutzt. Eine sichtbare Loginseite beantwortet diese Frage ebenso wenig wie eine alte Rechnung mit dem Produktnamen. Umgekehrt sollte ein deaktiviertes Plugin nicht als Begründung dienen, sämtliche anderen Sicherheitsupdates aufzuschieben: Die Roundcube-Veröffentlichungen enthalten mehrere voneinander unabhängige Korrekturen.

Quelle: Roundcube: Plugins aktivieren und deaktivieren, Roundcube: Sicherheitskorrekturen vom Mai, SOCRadar: Bedingungen der Betroffenheit.

Unsere kompakte Bestandsaufnahme

• Dienst: Welche Webmail-Adressen werden produktiv angeboten, und welche davon sind aus dem Internet erreichbar? Auch selten verwendete Zugänge in die Liste aufnehmen.
• Betreiber: Wer kann Anwendung und Konfiguration tatsächlich ändern? Einen namentlichen Kontakt und eine Vertretung festhalten, nicht nur „Hosting“ in ein Ticket schreiben.
• Softwarestand: Laufende Version, vollständige Paketbezeichnung, Bezugsquelle und gegebenenfalls Container-Image dokumentieren. Ein geplantes Update zählt noch nicht als installiert.
• Erweiterung: Ist virtuser_query wirksam aktiviert? Die Antwort mit einer lokalen Prüfung oder einer belastbaren Betreiberbestätigung belegen.
• Nachweis: Datum, prüfende Person und Ergebnis zusammen ablegen. Zugangsdaten und vollständige Konfigurationsdateien gehören nicht in breit zugängliche Tickets.

3. Versionsnummern richtig lesen: Upstream ist nicht Distributionspaket

Die Upstream-Versionen 1.6.16 und 1.7.1 markieren die ursprüngliche Korrektur dieses Fehlers. Roundcube empfiehlt in seiner Veröffentlichung vom 6. September die neueren Sicherheitsversionen 1.6.19 beziehungsweise 1.7.4 für produktive Installationen dieser Reihen. Distributionspakete können allerdings Sicherheitskorrekturen zurückportieren, ohne dieselbe Upstream-Nummer zu tragen: Der Debian Tracker führt für Bookworm bereits 1.6.5+dfsg-1+deb12u9 als korrigiert. Diese konkrete Angabe betrifft das Debian-Paket und ist keine Freigabe für beliebige Installationen mit „1.6.5“ im Namen. Unsere Empfehlung lautet daher, den vorgesehenen Wartungskanal beizubehalten: Distribution, Hostingplattform oder Upstream-Projekt. Nicht ungeprüft ein heruntergeladenes Archiv über eine verwaltete Installation kopieren. Lassen Sie sich die Behebung der konkreten CVE bestätigen und prüfen Sie zusätzlich den allgemeinen Sicherheitsstand des gewählten Zweigs.

Quelle: Roundcube: September-Updates, Debian: korrigierte Pakete für CVE-2026-48842.

Entscheidungshilfe für die IT-Leitung

• Verwundbarer Code und Plugin aktiv: Aus unserer Sicht dringender Änderungsbedarf; Update und Bewertung möglicher vorheriger Angriffe gemeinsam organisieren.
• Alter Softwarestand, Plugin nachweislich inaktiv: Diese konkrete Plugin-Bedingung liegt nicht vor; trotzdem weitere Sicherheitskorrekturen über den Wartungskanal einspielen.
• Korrigiertes Hersteller- oder Distributionspaket: Nachweis dokumentieren, Funktion prüfen und verbleibende Updates bewerten. Nicht allein auf eine verkürzte Versionsanzeige verlassen.
• Version oder Konfiguration unbekannt: Status als ungeklärt führen. Eine ausstehende Providerantwort ist keine Bestätigung, dass das System geschützt ist.

4. Ein kontrolliertes Update braucht eine fachliche Abnahme

Für die Umsetzung empfehlen wir einen kurzen, schriftlichen Änderungsplan: Verantwortliche Person, Sicherung von Konfiguration und Datenbank, Updatequelle, Wartungsfenster und Abnahme festlegen. Nach dem Einspielen sollte nicht nur die Startseite sichtbar sein. Testen Sie mit vorgesehenen Testkonten die tatsächlich verwendeten Anmeldeformen sowie Lesen und Versenden von Nachrichten. Falls die Benutzerzuordnung vom Plugin abhängt, gehört genau dieser Ablauf in die Abnahme. Erfassen Sie alle produktiven Instanzen und die Vorlagen, aus denen neue Instanzen entstehen, damit eine spätere Bereitstellung nicht versehentlich den alten Stand zurückbringt. Ein Rückkehrplan sollte ausdrücklich berücksichtigen, dass die Wiederherstellung einer verwundbaren Version erneut ein Sicherheitsproblem eröffnen würde. Diese Schritte sind unsere Betriebsempfehlung, kein von Roundcube vorgegebenener universeller Installationsablauf.

Wenn das Update nicht sofort möglich ist

• Die dokumentierte Deaktivierung entfernt ein Plugin aus der plugins-Liste. Prüfen Sie mit dem Betreiber, ob dies als vorübergehende Maßnahme für Ihren Anmeldeablauf geeignet ist.
• Lassen Sie eine Änderung nur durch befugte Administratoren durchführen und testen Sie anschließend die erlaubten Benutzerzuordnungen. Eine theoretisch sichere, aber unbenutzbare Anmeldung ist kein geordneter Betrieb.
• Bewerten Sie zusätzlich, ob der betroffene Webzugang vorübergehend eingeschränkt werden muss. Geschäftsführung und IT sollten Auswirkungen und zulässige Ausweichwege gemeinsam festlegen.
• Geben Sie jeder Zwischenlösung einen Verantwortlichen und einen verbindlichen Prüftermin. Die Plugin-Deaktivierung ersetzt nicht die anderen Sicherheitskorrekturen.

Quelle: Roundcube: dokumentierte Plugin-Deaktivierung, Roundcube: Umfang der Sicherheitsupdates.

5. Patchen und Vorfallsprüfung sind zwei getrennte Aufgaben

Bei einem möglicherweise exponierten System empfehlen wir, verfügbare Webserver-, Anwendungs- und Datenbankprotokolle gesichert aufzubewahren und fachkundig auf Auffälligkeiten prüfen zu lassen. Halten Sie fest, welche Zeiträume überhaupt abgedeckt sind; fehlende Aufzeichnungen sollten im Ergebnis als Erkenntnislücke erscheinen. Behaupten Sie weder aufgrund einzelner Fehlermeldungen einen erfolgreichen Angriff noch aufgrund unauffälliger Stichproben dessen sicheren Ausschluss. Die öffentliche Behördenwarnung liefert keine Opferliste oder konkreten Indikatoren für Ihre Installation. Bei belastbaren Verdachtsmomenten empfehlen wir einen geregelten Incident-Response-Prozess mit Beweissicherung, Eindämmung und Prüfung betroffener Zugänge. Ob zusätzliche Benachrichtigungen oder rechtliche Bewertungen erforderlich sind, sollte anhand des konkreten Falls mit den zuständigen Fachpersonen geklärt werden. Dieser Beitrag stellt keinen Nachweis eines Vorfalls in Ihrem Unternehmen dar.

Quelle: AV26-503: Umfang der veröffentlichten Warnung, SOCRadar: Einordnung und Grenzen der verfügbaren Informationen.

6. Übertragbar: derselbe Ablauf bei Java, Containern und CI/CD

Ein zweiter Vorgang aus dem August zeigt, dass dieser Ablauf nicht roundcubespezifisch ist: Amazon hat am 18. August 2026 außerplanmäßige Sicherheitsupdates für die laufenden Corretto-Linien veröffentlicht, nämlich 8.504.01.1 für Java 8, 11.0.32.10.1 für Java 11, 17.0.20.10.1 für Java 17, 21.0.12.9.1 für Java 21, 25.0.4.8.1 für Java 25 und 26.0.2.11.1 für Java 26. Adressiert werden unter anderem vier Schwachstellen: CVE-2026-61308 (CVSS 6,8), CVE-2026-70906 (7,5), CVE-2026-70907 (5,3) und CVE-2026-60589 (3,7). AWS bezeichnet die Veröffentlichung als Critical Security Patch Update; das benennt das Veröffentlichungsformat und nicht den Schweregrad jeder enthaltenen Schwachstelle – eine Abgrenzung, die in Kapitel 1 auch für die Roundcube-Meldung gegolten hat. Die Prüfschritte selbst wiederholen wir hier deshalb nicht, sondern nur das, was dieser Fall zusätzlich lehrt.

Was der Corretto-Fall zusätzlich lehrt, betrifft drei Ebenen, die eine Webmail-Installation nicht in dieser Form kennt. Erstens ist die Version einer Java-Laufzeit nicht automatisch die Version der im eigenen Haus genutzten Bibliotheken: Ein neuer Corretto-Build korrigiert die Laufzeit, aktualisiert aber weder Spring, Log4j, Netty noch Tomcat in der Anwendung – und umgekehrt ersetzt eine Aktualisierung dieser Abhängigkeiten keine gepatchte JVM. Beide Ebenen brauchen getrennte Nachweise. Zweitens sind unveränderliche Container-Images für reproduzierbare Rollouts nützlich, patchen sich aber nicht selbst: Ein aktualisiertes Paketrepository auf dem Host genügt nicht, solange das Image nicht neu gebaut, geprüft und ausgerollt wird. Drittens tragen Backports in Distributionspaketen andere Versionsnummern als der Upstream, weshalb die Bewertung distributions- und versionsspezifisch erfolgen muss – derselbe Gedanke wie in Kapitel 3.

Für die CI/CD-Pipeline gilt dasselbe Verfahren, nur an anderer Stelle: Läuft die Build-Strecke auf einem eigenen Pipeline-Image, ist auch dieses eine zu pflegende Instanz mit eigener Versionsangabe. Zu prüfen ist deshalb, welche Laufzeit der Build verwendet und welchen Stand das erzeugte Artefakt tatsächlich enthält. Unsere Empfehlung lautet, Versionsangaben deklarativ zu halten und anschließend zu verifizieren, statt sie aus dem Build-Erfolg abzuleiten – ein gelungener Build ist noch kein Nachweis für die Version des laufenden Prozesses. Diese Schritte sind unsere Betriebsempfehlung und keine Vorgabe der Hersteller.

Typische Fehler, die sich hier wiederholen

• Nur Serverpakete aktualisieren: Eingebettete Laufzeiten, Container und CI/CD-Images behalten ihren alten Stand.
• Laufzeit-Version mit Bibliotheksstand verwechseln: Ein korrigierter Corretto-Build sagt nichts über die Version der selbst genutzten Bibliotheken aus.
• Container-Image für gepatcht halten: Unveränderliche Images vereinfachen reproduzierbare Rollouts, ersetzen aber kein Neu-Bauen und Ausrollen des Images.
• CVSS-Zahl als Priorität lesen: CVE-2026-70906 liegt bei 7,5, wird laut Corretto-Changelog aber nur für Java 25 und 26 genannt; Erreichbarkeit und Datenfluss entscheiden über die Reihenfolge.
• Backports gegen Upstream-Nummern verrechnen: Ein Paket mit abweichender Versionsnummer ist nicht automatisch schlechter gepatcht – Beleg und Herkunft bleiben die Grundlage.

Der Corretto-Fall ist ein Nachrichtengespräch, die Methode ist es nicht: Welche Version wann betroffen war, veraltet schnell, die Reihenfolge aus Betroffenheitsklärung, Priorisierung, kontrolliertem Update, fachlicher Abnahme und getrennter Ursachenanalyse bleibt bestehen. Dieser Artikel behandelt den Vorgang vom 18. August 2026 und trifft keine Aussage über den aktuellen Patchstand im September 2026; für den Webmail-Betrieb bleibt es dabei, eine belegte Betreiberantwort nach dem Muster aus Kapitel 7 einzufordern.

Quelle: AWS: Amazon Corretto August 2026 Security Updates; Oracle: August 2026 CSPU – Java SE Risk Matrix; AWS-Dokumentation: What is Amazon Corretto 17?; AWS-Dokumentation: Corretto 17 auf Docker; AWS-Dokumentation: Downloads und Prüfsummen; AWS: Amazon Corretto

7. Was Geschäftsführer vom IT-Dienstleister verlangen sollten

Unsere Empfehlung für kleinere Unternehmen ist kein zusätzliches Großprojekt, sondern ein prüfbarer Betriebsnachweis. Bitten Sie Ihren Dienstleister um eine verständliche Antwort: Wird Roundcube eingesetzt, ist der konkrete Fehler behoben, und auf welcher Grundlage wurde das festgestellt? „Alles aktuell“ ohne Paketstand, Zeitpunkt oder Zuständigkeit ist für eine nachvollziehbare Entscheidung zu wenig. Vereinbaren Sie außerdem, wer künftig Sicherheitsmeldungen bewertet und wie Sie über notwendige Maßnahmen informiert werden. Bei mehreren Beteiligten sollte klar sein, wer den Anwendungscode pflegt und wer lediglich Server oder Netzwerk betreibt. Das Ziel ist nicht, jede technische Einzelheit selbst zu kontrollieren, sondern eine geschlossene Verantwortungskette zu erhalten. Ein gut dokumentiertes Ergebnis „Produkt nicht eingesetzt“ ist dabei ebenso brauchbar wie ein bestätigtes Update.

Formulierungsvorschlag für Ihre Anfrage

• Bitte bestätigen Sie, ob unsere produktiven Webmail-Zugänge Roundcube verwenden und welche laufenden Versionen beziehungsweise Pakete eingesetzt werden.
• Bitte prüfen Sie die wirksame Aktivierung von virtuser_query und bestätigen Sie den Patchstatus zu CVE-2026-48842 einschließlich möglicher Hersteller-Backports.
• Bitte nennen Sie durchgeführte Maßnahmen, Zeitpunkt und Ergebnis der Funktionstests sowie gegebenenfalls verbleibende Einschränkungen.
• Falls die Installation exponiert war: Bitte erläutern Sie, welche Protokolle verfügbar sind, welche Prüfung erfolgt und wer offene Punkte bearbeitet.

8. KI kann unterstützen – die Freigabe bleibt beim Betrieb

Für Teams mit KI-Werkzeugen empfehlen wir eine klar begrenzte Unterstützung: Ein Assistent kann aus freigegebenen Angaben eine Bestandsliste strukturieren, Herstellerhinweise zusammenfassen oder fehlende Nachweise markieren. Die Entscheidung „nicht betroffen“ sollte dagegen an nachvollziehbare technische Belege und eine verantwortliche Person gebunden bleiben. Lassen Sie keine produktiven Plugin-Einstellungen allein auf Basis einer generierten Zusammenfassung ändern. Geben Sie außerdem weder Konfigurationen mit Datenbankkennwörtern noch unverarbeitete Kundenprotokolle in beliebige externe Systeme. Für eine erste Prüfung genügt häufig ein minimierter Datensatz aus Produkt, Paketstand, Plugin-Status und Quellennachweis. Das ist unser vorgeschlagenes Kontrollmodell; wir behaupten weder, KI habe diesen Angriff verursacht, noch, ein bestimmtes KI-Produkt könne ihn zuverlässig erkennen.

Fazit: Eine konkrete Prüfung statt allgemeiner Alarmstimmung

Der Nachrichtenwert dieser Woche liegt nicht in einer neuen Versionsnummer, sondern in der aktualisierten Warnlage zu einem bereits korrigierten Fehler. Unsere Konsequenz für KMU ist entsprechend praktisch: Den eigenen Webmail-Betrieb identifizieren, Plugin und Patchstatus zusammen bewerten und Maßnahmen sauber abschließen. Wer keinen betroffenen Dienst betreibt, braucht daraus kein Migrationsprojekt abzuleiten. Wer dagegen eine ungeklärte Installation nutzt, sollte den Vorgang nicht mit einer allgemeinen Zusicherung beenden. Entscheidend sind ein nachvollziehbarer technischer Stand, eine benannte Verantwortung und ein ehrlicher Umgang mit möglichen Erkenntnislücken aus der Vergangenheit.

EIST Consulting unterstützt Sie bei der technischen Bestandsaufnahme, der Abstimmung mit Hostinganbietern und einem nachvollziehbaren Sicherheits- und Updateprozess.

Stand: 28. September 2026. Hersteller- und Behördenangaben wurden anhand der verlinkten Quellen geprüft. Umsetzungsvorschläge sind eigene Beratungseinordnung; es wurde kein Angriff auf eine Kundeninstallation untersucht.