Zammad-Lücken ausgenutzt: Welche Version selbst betriebene Ticketsysteme brauchen

Ein Einbruch über das Ticketsystem

Am 21. September 2026 griff ein Angreifer erstmals auf Systeme der Organisation DIVD zu. Nach Darstellung von DIVD kamen die Angreifer über zwei bis dahin unbekannte Lücken (sogenannte Zero-Days) im Ticketsystem Zammad herein. Zusammen erlaubten die beiden, Sitzungen angemeldeter Nutzer zu übernehmen, Programmcode auszuführen und die Rechte bis zum höchsten Konto des Servers auszuweiten, dem Konto root. Sicher abgeflossen sind laut DIVD Daten von Freiwilligen, etwa DIVD-E-Mail-Adressen und möglicherweise Kontaktdaten.

In einem Ticketsystem laufen Kundenanfragen zusammen und werden als Vorgänge, die Tickets, bearbeitet. Die beiden Lücken tragen die Kennungen CVE-2026-102489 und CVE-2026-102490. CVE-Kennungen sind öffentliche Nummern, unter denen Sicherheitslücken einheitlich geführt werden; der öffentliche Eintrag zu einer Kennung heißt CVE-Datensatz. Seit dem 2. Oktober 2026 stehen beide Lücken im Katalog der US-Behörde CISA für bekannte ausgenutzte Schwachstellen.

Ob Sie handeln müssen, hängt vor allem an einer Frage: Betreiben Sie Zammad selbst, oder mieten Sie es beim Hersteller? Wer es selbst betreibt, braucht Version 7.2.2 oder neuer. Dieser Beitrag gibt den Stand vom 9. Oktober 2026 wieder.

Was zwischen dem 21. September und dem 8. Oktober 2026 geschah

CISA begründet die Aufnahme mit Belegen für aktive Ausnutzung („evidence of active exploitation“). Die Frist im Katalog (5. Oktober 2026) gilt für US-Bundesbehörden, nicht für Betriebe in Deutschland, Österreich oder der Schweiz. CISA ermutigt aber alle Organisationen, sich bei der Wahl ihrer Prioritäten am Katalog zu orientieren.

Den Ablauf schildern beide Seiten unterschiedlich. Zammad gibt an, einen Bericht zu CVE-2026-102489 schon im August 2026 erhalten zu haben; DIVD nennt den 24. September 2026 als Meldedatum. Zum öffentlichen Scannen und zur Offenlegung durch DIVD schrieb Zammad am 1. Oktober 2026: „We do not consider this a responsible way to handle vulnerabilities.“ Wir geben beide Sichtweisen wieder, ohne sie zu bewerten. An dem, was Sie tun sollten, ändert der Streit nichts.

Dass der Angriff KI-gesteuert war, ist eine Einschätzung von DIVD vom 24. September 2026, keine gesicherte Feststellung.

Was die beiden Lücken bedeuten

CVE-2026-102489: Codeausführung aus der Ferne

CISA führt diese Lücke als „Session Fixation Vulnerability“. Eine Sitzung (Session) ist der Zustand, in dem das System Sie nach der Anmeldung als angemeldet kennt. DIVD führt die Lücke als Codeausführung aus der Ferne, der CVE-Datensatz unter dem Titel „Undisclosed RCE in Zammad v6.3 and higher“. RCE steht für Remote Code Execution: Ein Fremder bringt auf dem Server Programmcode zum Laufen. Welche Versionen wirklich angreifbar sind, ist umstritten. Dazu gleich mehr.

CVE-2026-102490: vom Dienstkonto zu root

Die zweite Lücke ist eine lokale Rechteausweitung. Wer auf dem Server bereits Programmcode unter dem Dienstkonto zammad ausführen kann, also unter dem Konto, unter dem die Software läuft, kann sich damit volle root-Rechte auf dem Rechner verschaffen. Zammad betont, dass sich diese Lücke allein nicht aus der Ferne ausnutzen lässt. Für den Einbruch bei sich selbst beschreibt DIVD aber genau die Kombination beider Lücken.

Betroffen sind laut Zammad-Hinweis vom 8. Oktober 2026 nur Installationen aus den DEB- und RPM-Paketen (packager.io), also aus fertigen Installationspaketen für Linux-Server, und zwar alle veröffentlichten Paketversionen bis einschließlich 7.2.1. Installationen aus dem Quellcode und mit den offiziellen Container-Images sind nicht betroffen. Ein Container-Image ist ein fertig gepacktes Abbild der Software samt allem, was sie zum Laufen braucht; gestartet wird es zum Beispiel mit Docker.

Zur Schwere nennt der CVE-Datensatz nach dem Bewertungssystem CVSS 4.0, einer Skala bis 10, je zwei Werte: 8,7 und 9,4 für CVE-2026-102489, 8,5 und 9,4 für CVE-2026-102490. Zammad selbst stuft CVE-2026-102490 als „High“ mit 8,5 ein. Die eine richtige Zahl gibt es hier nicht.

Welche Versionen betroffen sind: drei Quellen, drei Angaben

Bei CVE-2026-102489 widersprechen sich die Quellen:

• DIVD (Fallseite, zuletzt geändert am 1. Oktober 2026): ausnutzbar in den Versionen 6.3.0 bis 6.5.4. Die Versionen 7.0.0 bis 7.1.3 seien betroffen, wegen der Umgebungsbedingungen aber nicht ausnutzbar. Empfehlung: Update auf Zammad 7.
• CVE-Datensatz (aktualisiert am 8. Oktober 2026): 6.3.0 bis unter 6.5.4 betroffen. Für Versionen unter 6.3.0 und für 7.0.0 bis unter 7.1.3 lautet der Status „unbekannt“.
• Zammad (Hinweis vom 5. Oktober 2026): ausnutzbar nur in 6.5 und älter, ab 7.0 in der Praxis nicht betroffen. Den betroffenen Code hat Zammad in Version 7.2.0 zusätzlich gehärtet.

Wir bilden daraus keinen eigenen Versionsbereich. Für Ihre Entscheidung brauchen Sie ihn auch nicht, wie der nächste Abschnitt zeigt.

Bei CVE-2026-102490 ist das Bild klarer. Der CVE-Datensatz führt seit dem 8. Oktober 2026 die Versionen 1.5.0 bis unter 7.2.2 als betroffen und 7.2.2 als nicht betroffen. Das deckt sich mit dem Zammad-Hinweis: betroffen bis einschließlich 7.2.1, korrigiert in 7.2.2. Die DIVD-Fallseite nennt mit Stand 1. Oktober 2026 noch 1.5.0 bis 7.1.0-alpha. Diese Angabe ist überholt.

Zielstand: Zammad 7.2.2 oder neuer

Wer Zammad selbst betreibt, braucht Version 7.2.2 oder neuer (Stand 9. Oktober 2026). Zammad liefert Sicherheitskorrekturen nach eigener Richtlinie nur für die jeweils neueste stabile Version; die Versionen 6.5 und älter bekommen keine Sicherheitsupdates mehr. Außerdem bringen die beiden Sicherheitsversionen vom Oktober 2026 mehr als nur die zwei ausgenutzten Lücken:

• Zammad 7.2.1 (6. Oktober 2026) behebt 27 Schwachstellen. Darunter ist eine Umgehung der Mehrfaktor-Anmeldung über den Ablauf zur E-Mail-Bestätigung, die Zammads GitHub-Hinweis als „Critical“ einstuft. Eine andere erlaubte Codeausführung aus der Ferne über die Konfiguration von Automatisierungen. Eine dritte betraf die Kanalverwaltung, also die Wege, über die Anfragen hereinkommen: Deren Schnittstellen gaben gespeicherte Zugangsdaten im Klartext zurück.
• Zammad 7.2.2 (8. Oktober 2026) schließt CVE-2026-102490 in den DEB- und RPM-Paketen.

Ob eine der 27 Lücken aus 7.2.1 ausgenutzt wurde, sagen die Quellen nicht. Zammads Forenbeitrag vom 5. Oktober 2026 empfahl noch ein Update auf 7.2.0. Seitdem sind die beiden Sicherheitsversionen erschienen.

Gemietet, Paket oder Docker: was für Ihre Installation gilt

„Selbst betrieben“ heißt nicht, dass der Server in Ihrem Büro stehen muss. Auch eine Installation beim Hoster oder bei einem Dienstleister zählt dazu, sobald nicht Zammad selbst sie betreibt. Für diesen Fall schreibt Zammad in den Versionshinweisen: „We strongly advise upgrading to the latest version of Zammad immediately to ensure your system is protected.“ Anleitungen für Paket- und Docker-Installationen stehen in der Zammad-Dokumentation.

Was Sie Ihren Dienstleister oder Hoster fragen

Oft hat jemand anderes Zammad eingerichtet und pflegt es. Diese Fragen helfen beim Gespräch:

1. Läuft bei uns Zammad, und wenn ja: beim Hersteller gemietet oder selbst betrieben, und wo?
2. Welche Version läuft? Ist es 7.2.2 oder neuer, und falls nicht, bis wann wird aktualisiert?
3. Wie ist Zammad installiert: aus DEB- oder RPM-Paketen, mit den Container-Images oder aus dem Quellcode?
4. Lief vor der Aktualisierung eine Version 6.5 oder älter? Für diese Versionen gibt es keine Sicherheitsupdates mehr.
5. Wer hat Zugang zum Server? Zammad empfahl am 5. Oktober 2026, den Serverzugang auf vertrauenswürdige Administratoren zu beschränken.
6. Ist die Installation aus dem Internet erreichbar, und ist eine Benachrichtigung von DIVD eingegangen? DIVD begann am 26. September 2026, Betreiber verwundbarer Installationen zu benachrichtigen.
7. Wurde geprüft, ob es Spuren eines Angriffs gibt? DIVD stellt ein Prüfskript bereit, das Zammad-Logdateien auf Anzeichen einer Kompromittierung durchsuchen soll.

Was offen ist

• Welche Versionen von CVE-2026-102489 wirklich angreifbar sind. DIVD, CVE-Datensatz und Zammad sagen Unterschiedliches. In der Liste der Zammad-Sicherheitshinweise auf GitHub findet sich zu dieser Kennung kein eigener Hinweis (Stand 9. Oktober 2026). Die Einordnung des Herstellers steht im Hinweis vom 5. Oktober 2026.
• Wann Zammad zuerst von der Lücke erfuhr. Laut Zammad im August 2026, laut DIVD am 24. September 2026.
• Der Zammad-Hinweis vom 5. Oktober 2026 ist nicht nachgeführt. Zu CVE-2026-102490 steht dort noch, das Team arbeite an einer Lösung; Version 7.2.2 kommt darin nicht vor (Stand 9. Oktober 2026). Die Korrektur beschreiben der GitHub-Hinweis vom 8. Oktober 2026 und die Versionshinweise zu 7.2.2.
• Wie verbreitet die Angriffe sind. Wie viele Installationen angreifbar sind und ob es außer bei DIVD weitere Einbrüche gab, geht aus den Quellen nicht hervor. Ob die Lücken für Erpressungssoftware (Ransomware) genutzt werden, führt der CISA-Katalog als „Unknown“.
• Ob nach 7.2.2 eine neuere Version erschienen ist. Am 9. Oktober 2026 war 7.2.2 die neueste. Vor dem Update lohnt ein Blick in die Versionsübersicht von Zammad.

Wer pflegt das Ticketsystem?

Ist ein Ticketsystem einmal eingerichtet und läuft, gerät leicht aus dem Blick, wer es aktualisiert. Dieselbe Frage stellt sich bei jeder Webanwendung, die Sie selbst betreiben, etwa bei einer WordPress-Website (siehe unseren Beitrag zur WordPress-Lücke CVE-2026-87902). Klären Sie mit Ihrem Dienstleister oder Hoster, wer Zammad bei Ihnen aktualisiert und woran Sie erkennen, dass es geschehen ist. Bei der Einordnung solcher Sicherheitsmeldungen unterstützen wir Sie gern.