Ticketsystem absichern: Was die Angriffe auf Zammad für KMU bedeuten

Ein Ticketsystem gilt in vielen Betrieben als unkritisches Hilfswerkzeug: Kundenanfragen rein, Antworten raus. Tatsächlich sammelt sich dort über Jahre fast alles, was ein Angreifer sucht – Kontaktdaten, Vertragsdetails, Screenshots, Anhänge und nicht selten Passwörter im Klartext. Aktuelle Angriffe auf die Helpdesk-Software Zammad sind ein guter Anlass, das eigene Ticketsystem abzusichern und seinen Platz im Patch-Plan zu überdenken.

Anlass: Angriffe auf Zammad laufen bereits

Laut heise online warnt die US-Sicherheitsbehörde CISA vor Angriffen auf Schwachstellen in Zammad, die bereits aktiv ausgenutzt werden. Zammad ist ein quelloffenes, webbasiertes Ticketsystem, das im deutschsprachigen Raum weit verbreitet ist – auch bei kleineren Unternehmen, die es selbst betreiben.

Dem Bericht zufolge geht es um zwei Lücken:

Einzeln sind beide Lücken als „hoch” eingestuft. In Kombination ergibt sich laut heise ein CVSS-Wert von 9.4 und damit die Einstufung „kritisch”: Die erste Lücke bringt den Angreifer auf den Server, die zweite macht ihn dort zum Administrator.

Was Betreiber jetzt tun sollten

Als Gegenmaßnahme nennt der Bericht das Update auf Zammad 7.2.0. Für die Rechteausweitung hat der Hersteller demnach noch keine Korrektur veröffentlicht, arbeitet aber daran. Das niederländische Institut DIVD rät, auf Version 7 zu aktualisieren oder die Instanz vom Netz zu nehmen, bis das möglich ist.

Wer noch eine 6er-Version betreibt, sollte also nicht auf das nächste Wartungsfenster warten. Prüfen Sie die Hinweise des Herstellers auf den aktuellen Stand, bevor Sie handeln – bei laufenden Angriffen ändern sich Empfehlungen innerhalb weniger Tage.

Warum das Ticketsystem ein lohnendes Ziel ist

Es enthält mehr, als man denkt

Tickets sind ein ungefiltertes Archiv des Kundenkontakts. Typischerweise finden sich dort:

• Namen, Anschriften, Telefonnummern und E-Mail-Adressen von Kunden
• Rechnungen, Verträge und Ausweiskopien als Anhang
• Screenshots mit sichtbaren internen Daten
• Zugangsdaten, die Kunden oder Kollegen „nur schnell” per Ticket geschickt haben
• interne Notizen über Kunden, Störungen und Schwachstellen

Bei einem IT-Dienstleister, einer Agentur oder einem Softwarehaus beschreibt das Ticketsystem außerdem die Infrastruktur der Kunden. Ein Einbruch dort betrifft dann nicht nur den eigenen Betrieb.

Es ist bewusst von außen erreichbar

Kunden sollen Tickets über ein Portal anlegen, Mitarbeiter von unterwegs antworten. Das Ticketsystem steht deshalb in vielen Betrieben direkt im Internet – anders als Dateiserver oder Warenwirtschaft. Jede Lücke, die sich ohne Anmeldung oder mit einem einfachen Kundenkonto ausnutzen lässt, ist damit sofort für Angreifer weltweit erreichbar. Welche Dienste Ihres Unternehmens von außen sichtbar sind, zeigt ein Blick auf die externe Angriffsfläche.

Es ist mit vielen anderen Systemen verbunden

Ein Ticketsystem arbeitet selten allein. Es ruft Postfächer ab und versendet E-Mails im Namen der Firma, hängt am Verzeichnisdienst, an der Telefonanlage, am Chat und über Schnittstellen an CRM oder Monitoring. Die dafür nötigen Passwörter und API-Schlüssel liegen in der Konfiguration. Wer den Server übernimmt, erbt diese Zugänge – und kann zum Beispiel täuschend echte E-Mails aus laufenden Kundengesprächen heraus verschicken.

Es fällt im Patch-Plan durch das Raster

Windows, Firewall und Mailserver haben meist einen festen Update-Rhythmus. Das Ticketsystem wurde dagegen irgendwann eingerichtet, läuft seitdem zuverlässig und gehört niemandem so richtig. Größere Versionssprünge werden verschoben, weil sie Aufwand bedeuten. Genau diese Situation zeigt der aktuelle Fall: Angreifbar sind die Installationen, die auf einem älteren Hauptzweig stehen geblieben sind.

Ticketsystem absichern in sieben Schritten

1. Version und Zuständigkeit klären

Welche Helpdesk-Software läuft, in welcher Version, auf welchem Server – und wer ist dafür verantwortlich? Steht das nirgends, ist das die erste Lücke. Das System gehört ins IT-Inventar und in den regulären Patch-Management-Prozess.

2. Auf einem gepflegten Versionszweig bleiben

Sicherheitskorrekturen erscheinen nur für aktuelle Zweige. Planen Sie Versionssprünge deshalb ein, bevor ein Notfall sie erzwingt: Datensicherung, Testlauf auf einer Kopie, dann das Update. Abonnieren Sie die Sicherheitsmeldungen des Herstellers, damit Warnungen nicht erst über die Presse ankommen.

3. Erreichbarkeit einschränken

Trennen Sie, was Kunden brauchen, von dem, was nur Mitarbeiter brauchen. Die Agenten- und Administrationsoberfläche muss nicht offen im Internet stehen – sie lässt sich hinter ein VPN wie WireGuard oder einen Reverse Proxy mit vorgeschalteter Anmeldung legen. Der Server selbst gehört in ein eigenes Netzsegment, aus dem er nicht frei ins interne Netz kommt.

4. Anmeldung härten

Alle Agenten- und Admin-Konten erhalten Multi-Faktor-Authentifizierung, idealerweise über eine zentrale Anmeldung per Single Sign-on. Konten ausgeschiedener Mitarbeiter werden gelöscht, Adminrechte auf wenige Personen begrenzt.

5. Verknüpfte Zugänge minimieren

Das Postfach, das das Ticketsystem abruft, braucht keine weitergehenden Rechte. API-Token sollten nur das dürfen, was die jeweilige Integration erfordert. Nach einem Sicherheitsvorfall – oder wenn eine Instanz verwundbar im Netz stand – werden alle hinterlegten Passwörter und Schlüssel getauscht.

6. Daten im System begrenzen

Zugangsdaten gehören nicht ins Ticket. Legen Sie fest, dass Passwörter über einen Passwortmanager oder einen anderen sicheren Weg übermittelt werden, und entfernen Sie Altlasten. Löschfristen für abgeschlossene Tickets reduzieren den Schaden im Ernstfall und sind nach DSGVO ohnehin gefordert.

7. Protokolle auswerten und Wiederherstellung testen

Ungewöhnliche Anmeldungen, neue Adminkonten oder unbekannte Prozesse auf dem Server sollten auffallen. Leiten Sie die Protokolle an eine zentrale Stelle weiter und prüfen Sie, ob sich das Ticketsystem samt Datenbank und Anhängen aus der Sicherung tatsächlich wiederherstellen lässt.

Wenn die eigene Instanz betroffen war

Lief eine verwundbare Version längere Zeit offen im Internet, reicht das Update allein nicht. Prüfen Sie Server und Anwendung auf Spuren eines Zugriffs: unbekannte Benutzer, geänderte Einstellungen, neue Dateien, auffällige ausgehende Verbindungen. Lässt sich ein Zugriff nicht ausschließen, ist der Server neu aufzusetzen und alle hinterlegten Zugangsdaten sind zu erneuern. Sind personenbezogene Daten abgeflossen, läuft außerdem die 72-Stunden-Frist für die Meldung an die Aufsichtsbehörde.

Was das für KMU in Sachsen bedeutet

Selbst betriebene Open-Source-Software ist für ostdeutsche KMU eine gute Wahl: keine Lizenzkosten pro Benutzer, Daten im eigenen Haus, keine Abhängigkeit von einem US-Anbieter. Viele Betriebe in Dresden und Sachsen – vom Softwarehaus über den Handwerksbetrieb mit Kundendienst bis zur Hausverwaltung – arbeiten deshalb mit einem eigenen Ticketsystem. Der Preis dafür ist Verantwortung: Wer selbst betreibt, muss selbst aktualisieren. Das ist kein Argument gegen Open Source, sondern für einen festen Wartungsprozess.

Sie suchen Unterstützung in Dresden?

Rexoma hilft KMU bei der Absicherung von Ticketsystemen und Helpdesk-Software: Prüfung der eingesetzten Version, Update und Migration auf einen gepflegten Zweig, Absicherung per OPNsense-Firewall und WireGuard VPN, Betrieb auf gehärteten Linux-Servern sowie laufende Betreuung mit festem Patch-Rhythmus. Sprechen Sie uns an – als IT-Dienstleister aus Dresden sind wir für Betriebe in ganz Sachsen schnell vor Ort.

FAQ

Welche Zammad-Versionen sind von den aktuellen Angriffen betroffen?

Laut heise online lässt sich die Lücke zur Codeausführung (CVE-2026-102489) in den Versionen 6.3.0 bis 6.5.4 ausnutzen. Die Rechteausweitung (CVE-2026-102490) betrifft einen deutlich größeren Versionsbereich. Maßgeblich sind die aktuellen Sicherheitshinweise des Herstellers.

Reicht es, das Ticketsystem hinter ein VPN zu stellen?

Für die Agenten- und Adminoberfläche ist das eine sehr wirksame Maßnahme. Ein Kundenportal muss aber meist öffentlich erreichbar bleiben. Zugriffsbeschränkung ersetzt deshalb keine Updates – beides gehört zusammen.

Sind Cloud-Ticketsysteme sicherer als selbst betriebene?

Nicht automatisch. Bei einem gehosteten Dienst übernimmt der Anbieter die Updates, dafür liegen die Daten außer Haus und Sie sind auf dessen Sorgfalt angewiesen. Selbst betriebene Systeme sind sicher, wenn Updates, Zugriffsschutz und Datensicherung verlässlich organisiert sind.

Was mache ich, wenn ein Update kurzfristig nicht möglich ist?

Nehmen Sie die Instanz vom Internet oder beschränken Sie den Zugriff auf das interne Netz und VPN, bis das Update eingespielt ist. Ein paar Tage Tickets per E-Mail und Telefon sind verkraftbar – ein übernommener Server mit allen Kundendaten nicht.

Dürfen Passwörter in Tickets stehen?

Nein. Tickets werden lange aufbewahrt, von vielen Personen gelesen und oft per E-Mail weiterverteilt. Zugangsdaten sollten über einen Passwortmanager mit Freigabefunktion übermittelt und nach Abschluss des Vorgangs geändert werden.