Zammad-Lücken CVE-2026-102489: Wer jetzt handeln muss
Die US-Behörde CISA führt zwei Lücken im Ticketsystem Zammad als ausgenutzt, verkettet bis zu Root-Rechten. Der Hersteller sieht nur alte Versionen betroffen. Was stimmt, wer handeln muss und was Betreiber jetzt tun sollten.
Hinweis: Dieser Beitrag wurde mit KI-Unterstützung erstellt und vor der Veröffentlichung automatisch gegen die unten genannten Quellen geprüft. Die redaktionelle Durchsicht steht noch aus.
Was ist bei Zammad passiert?
Im Helpdesk- und Ticketsystem Zammad sind zwei Sicherheitslücken bekannt geworden, CVE-2026-102489 und CVE-2026-102490, die zusammen bis zu vollen Administratorrechten auf dem Server führen können. Die US-Cybersicherheitsbehörde CISA hat beide am 2. Oktober 2026 in ihren Katalog aktiv ausgenutzter Schwachstellen aufgenommen. Gemeldet wurden sie über das niederländische Institut DIVD unter dem Fall DIVD-2026-00015.
Nach dem Eintrag der CISA zu CVE-2026-102489 (öffnet in neuem Tab) handelt es sich um eine Session-Fixation-Lücke, die zur Ausführung von Schadcode als Systemnutzer von Zammad führen kann. Der Eintrag zu CVE-2026-102490 (öffnet in neuem Tab) beschreibt eine fehlerhafte Rechteverwaltung, über die dieser lokale Nutzer zu Root-Rechten aufsteigen kann; beide Lücken lassen sich verketten.
Ticketsysteme sind für Angreifer interessant, weil in ihnen die Kommunikation mit Kunden zusammenläuft: Namen, E-Mail-Adressen, Vertragsdetails und oft Anhänge. Wer ein solches System übernimmt, hat Zugriff auf genau die Daten, die ein Unternehmen am meisten schützen muss.
Welche Zammad-Versionen betroffen sind
Der Hersteller schränkt die Betroffenheit deutlich ein. Laut dem Sicherheitshinweis von Zammad vom 5. Oktober 2026 (öffnet in neuem Tab) ist CVE-2026-102489 nur auf Zammad 6.5 und älteren Versionen ausnutzbar, wegen der Laufzeitumgebung, die diese Versionen verwenden. Zammad 7.0 und neuer sind nach Angabe des Herstellers in der Praxis nicht betroffen.
Die Versionen 6.5 und älter erhalten seit einiger Zeit keine Sicherheitsupdates mehr. Für Betreiber, die noch eine solche Version einsetzen, ist die Lage damit eindeutig: Sie betreiben ein System ohne Herstellerunterstützung mit einer ausgenutzten Lücke. Als zusätzliche Härtung hat Zammad den betroffenen Code in Version 7.2.0 geändert.
Maßgeblich ist die Version, die die Zammad-Installation selbst anzeigt. Wer das System über einen Dienstleister betreibt, sollte die Versionsangabe schriftlich anfordern, statt sich auf eine allgemeine Zusage zu verlassen. Eine genaue Versionsnummer lässt sich später nachprüfen, eine Zusage nicht.
CVE-2026-102490: lokale Rechteausweitung
CVE-2026-102490 ist nach Einschätzung des Herstellers eine lokale Rechteausweitung, die sich nicht allein aus der Ferne ausnutzen lässt. Ein Angreifer braucht vorher Zugang zum Server, auf dem Zammad läuft, und kann dann seine Rechte erweitern. Gefährlich wird die Lücke also vor allem in Verbindung mit einem anderen Weg auf den Server, etwa über CVE-2026-102489 auf einer alten Version.
Zammad führt die Lücke auf einen bestätigten Fehler im Paketdienst packager.io zurück, über den Installationspakete bereitgestellt werden, und arbeitet nach eigener Angabe an einer Lösung. Bis dahin empfiehlt der Hersteller, den Zugang zum Server auf vertrauenswürdige Administratoren zu beschränken.
Bemerkenswert ist der Ablauf der Offenlegung: Laut Zammad wurden Informationen zu CVE-2026-102490 veröffentlicht, bevor der Hersteller die technischen Details zur Prüfung erhalten hatte. Inzwischen liegen sie vor, und Zammad behandelt den Fall nach eigener Aussage mit hoher Priorität.
Warum die CISA beide Lücken als ausgenutzt führt
Die CISA nimmt eine Lücke in ihren Katalog auf, wenn sie Belege für eine Ausnutzung hat. Das bedeutet nicht, dass jede Installation angreifbar ist, sondern dass Angriffe auf verwundbare Installationen stattfinden. Die Frist für US-Bundesbehörden lief bis zum 5. Oktober 2026 und ist damit abgelaufen.
Die scheinbar widersprüchlichen Aussagen passen zusammen: Die Behörde beschreibt die Lücken und ihre Kette, der Hersteller grenzt ein, welche Versionen tatsächlich betroffen sind. Für Betreiber folgt daraus keine Entwarnung, sondern eine klare Prüfaufgabe: Welche Version läuft, und wer hat Zugang zum Server?
Auffällig ist die Reihenfolge: Die CISA hat beide Lücken am 2. Oktober 2026 in ihren Katalog aufgenommen, der Hinweis des Herstellers folgte am 5. Oktober. Wer nur die Seiten des Herstellers verfolgt, hätte in diesem Fall drei Tage später von den Angriffen erfahren. Für Unternehmen in Deutschland ist die Frist der CISA nicht verbindlich, der Katalog ist aber eine der schnellsten öffentlichen Quellen dafür, welche Lücken gerade tatsächlich angegriffen werden. Ein Blick dort hinein gehört deshalb in jede regelmäßige Prüfung der eigenen Systeme.
Was Betreiber von Zammad jetzt tun sollten
Der erste Schritt ist die Versionsprüfung. Läuft Zammad 6.5 oder älter, gehört das Update auf eine unterstützte Version ganz oben auf die Liste, weil diese Versionen weder gegen CVE-2026-102489 geschützt sind noch weitere Sicherheitsupdates erhalten. Bei einem Sprung über mehrere Hauptversionen lohnt eine Sicherung und ein Test in einer Kopie der Installation.
Der zweite Schritt betrifft den Server: Wer kann sich dort anmelden, über welche Wege, und sind alle diese Zugänge noch nötig? Weniger Zugänge bedeuten weniger Möglichkeiten, CVE-2026-102490 auszunutzen. Wer die Plattform nicht selbst betreuen will, kann Hosting und Deployment so aufsetzen lassen, dass Zugänge und Updates klar geregelt sind.
Der dritte Schritt ist, die Hinweise des Herstellers zu verfolgen, bis die Lösung für CVE-2026-102490 erschienen ist, und sie dann zeitnah einzuspielen. Feste Zuständigkeiten für solche Updates gehören in den Vertrag für Wartung und Support.
Grenze: was ein Katalogeintrag aussagt und was nicht
Ein Eintrag im Katalog der CISA sagt aus, dass eine Lücke ausgenutzt wird, nicht, dass jede Installation des Produkts angreifbar ist. Bei Zammad zeigt der Hinweis des Herstellers, dass die Fernausnutzung an alte Versionen gebunden ist. Wer eine aktuelle Version mit beschränktem Serverzugang betreibt, ist deutlich weniger gefährdet als die Schlagzeile vermuten lässt.
Umgekehrt ist die Einschätzung eines Herstellers keine unabhängige Prüfung. Sie beschreibt den Stand der Analyse zum Zeitpunkt des Hinweises und kann sich ändern, wenn neue Details bekannt werden. Das Bundesamt für Sicherheit in der Informationstechnik beschreibt auf seiner Seite zum Schutz von Servern (öffnet in neuem Tab) Schwachstellen in Betriebssystemen und Anwendungen als Eintrittstore für Cyber-Angriffe; eine aktuelle Version allein ersetzt deshalb keinen gut abgesicherten Server.
Und schließlich: Ein Update schließt die Lücke, entfernt aber keine Spuren eines früheren Angriffs. Lief eine alte Version offen im Internet, gehören nach dem Update die Protokolle geprüft und die Zugangsdaten der Administratoren erneuert.
Nächste Schritte für Unternehmen mit Ticketsystem
Ein Ticketsystem verarbeitet personenbezogene Daten von Kunden und gehört deshalb in jede Sicherheitsplanung, auch wenn es als „nur Support-Werkzeug" gilt. Ein Sicherheitsaudit klärt, welche solcher Anwendungen aus dem Internet erreichbar sind, wer für ihre Updates zuständig ist und wer Zugang zu den Servern hat.
Wie man vorgeht, wenn Hinweise auf einen Einbruch auftauchen, beschreibt der Beitrag Website gehackt – was tun; die ersten Schritte lassen sich auf ein übernommenes Ticketsystem übertragen. Dass auch Standardsoftware am Arbeitsplatz zeitnah Updates braucht, zeigt der Patchday im Oktober 2026.