Zwei Zammad-Zero-Days ermöglichen KI-gestütztem Angreifer Root-Zugriff auf DIVD-Systeme

DIVD führt den Netzwerkeinbruch auf eine Exploit-Kette aus zwei Schwachstellen zurück

Das niederländische Institut für die Offenlegung von Schwachstellen (Dutch Institute for Vulnerability Disclosure, DIVD) führt einen kürzlich erfolgten Netzwerkeinbruch auf zwei bislang unbekannte Schwachstellen in Zammad zurück. Die Open-Source-Plattform wird für Helpdesk- und Support-Tickets eingesetzt.

Laut Berichten über die DIVD-Untersuchung kombinierte der Angreifer CVE-2026-102489 und CVE-2026-102490, um die Zammad-Umgebung von DIVD zu kompromittieren. Die Exploit-Kette soll Session Hijacking, Remote Code Execution und eine Privilege Escalation vom Zammad-Dienstkonto bis zu Root ermöglicht haben.

Anschließend verschaffte sich der Eindringling Zugang zu weiteren Diensten, las Informationen aus DIVD-Systemen aus und exfiltrierte Daten. Netzwerksegmentierung und die Maßnahmen der Organisation zur Reaktion auf den Vorfall verhinderten laut DIVD, dass sich der Angreifer weiter im Netzwerk ausbreiten konnte.

Zum Zeitpunkt des zitierten Berichts lief die Untersuchung noch. DIVD kündigte ein weiteres Update für „morgen“ an, nannte jedoch keinen genauen Veröffentlichungstermin.

Vom gestohlenen Sitzungskontext zur Kontrolle mit Root-Rechten

Die beiden Schwachstellen scheinen sich ergänzt zu haben, statt jeweils für sich genommen eine Wirkung zu entfalten. DIVD beschrieb eine Angriffskette, die mit der Übernahme einer authentifizierten Sitzung begann und schließlich die Ausführung beliebigen Codes ermöglichte.

Von dort aus soll der Angreifer die Beschränkungen des Zammad-Kontos überwunden und Root-Rechte erlangt haben. Root-Zugriff verleiht einem Prozess auf einem typischen Linux-System die höchste Berechtigungsstufe. Dadurch ist die abschließende Privilege Escalation besonders schwerwiegend – auch ohne veröffentlichten CVSS-Score.

Die gemeldete Angriffskette lässt sich wie folgt zusammenfassen:

1. Die Ausnutzung der Zammad-Schwachstellen ermöglichte Session Hijacking.
2. Der kompromittierte Sitzungskontext wurde für Remote Code Execution genutzt.
3. Der Angreifer eskalierte vom Zammad-Konto zu Root.
4. Der Angriff weitete sich auf weitere Dienste aus, die aus der betroffenen Umgebung erreichbar waren.
5. Vor den Eindämmungsmaßnahmen, die eine weitere Ausbreitung begrenzten, wurden Daten abgerufen und exfiltriert.

Im vorliegenden Bericht wird nicht erläutert, welche Schwachstelle welche Phase ermöglichte, wie die Sitzung übernommen wurde oder welcher Mechanismus die Remote Code Execution ermöglichte. Auch Proof-of-Concept-Code, konkrete Request-Muster und weitere Details zur Ausnutzung fehlen.

Das erschwert es Verteidigern, allein anhand der öffentlich verfügbaren Informationen gezielte Erkennungsmaßnahmen für die einzelnen Schwachstellen zu entwickeln. An der gemeldeten Auswirkung ändert das nichts: Laut DIVD wurden die Schwachstellen erfolgreich miteinander kombiniert und gegen die eigene Infrastruktur eingesetzt.

DIVD zufolge steuerte ein KI-Agent den Angriff

Besonders bemerkenswert ist die Einschätzung von DIVD, dass ein KI-Agent den Angriff steuerte und eigenständig über seine nächsten Schritte entscheiden konnte.

Die Organisation zufolge durchlief der Agent innerhalb von Sekunden die Phasen Ausnutzung, Privilege Escalation, Zugriff auf Dienste und Datendiebstahl – ohne während dieser Abfolge von außen gesteuert zu werden. DIVD berichtete außerdem, dass das System Erklärungen zu seinen Entscheidungen hinterließ, anhand derer die Ermittler den Angriff rekonstruierten.

Diese Einschätzung sollte nicht über die Erkenntnisse von DIVD hinaus verallgemeinert werden. Der Bericht schreibt dem Agenten in diesem konkreten Vorfall autonome Entscheidungen zu. Er belegt jedoch weder, wie der Angreifer das System entwickelt hat, noch welches Modell zum Einsatz kam oder wie viel Vorbereitung der automatisierten Aktivität vorausging.

Das hohe Tempo ist aus operativer Sicht relevant. Eine automatisierte Angriffskette, die Zugriffsrechte bewertet und sofort passende Folgeschritte auswählt, kann mehrere Phasen eines Angriffs auf ein Zeitfenster verkürzen, das für ein manuelles Eingreifen zu knapp ist. Abwehrmaßnahmen müssen Aktivitäten daher automatisch stoppen oder eindämmen können, statt sich ausschließlich darauf zu verlassen, dass ein Analyst jeden einzelnen Schritt rechtzeitig bemerkt und darauf reagiert.

In diesem Fall trug die Netzwerksegmentierung dazu bei, die Auswirkungen zu begrenzen. Der Angreifer erreichte zwar weitere Dienste, doch laut DIVD verhinderten die Kontrollen eine tiefergehende Ausbreitung im Netzwerk.

Für Zammad-Nutzer gibt es keine genaue Angabe zu betroffenen Versionen

Zammad ist sowohl als selbst gehostete als auch als gehostete Helpdesk-Plattform verfügbar. Sie unterstützt die Bearbeitung von Kundenanfragen, IT-Support-Abläufe und internes Ticketmanagement. Dadurch kann sie ein attraktives Ziel sein: In Ticketsystemen können sensible Gespräche gespeichert sein, außerdem sind sie oft mit anderen Unternehmensdiensten verbunden.

Der Anbieter gibt an, mehr als 2.000 Kunden und 55.000 Nutzer zu haben. Im Bericht werden unter anderem De’Longhi, Amnesty International und NextCloud als Zammad-Nutzer genannt. Dass sie in diesem Zusammenhang als Kunden aufgeführt werden, ist kein Beleg dafür, dass ihre Systeme angegriffen oder kompromittiert wurden.

In der zitierten Mitteilung werden die verwundbaren Zammad-Versionen nicht genannt. Es fehlen außerdem Angaben zu betroffenen Versionen, behobenen Patch-Ständen und Produktkonfigurationen, die für eine Ausnutzung erforderlich wären.

Administratoren können daher nicht zuverlässig feststellen, ob sie betroffen sind, indem sie ihre Installation mit einer detaillierten Liste verwundbarer Versionen abgleichen. Die Empfehlung von DIVD ist allgemeiner: Auf Zammad Version 7 aktualisieren, die das Institut als sicher einstuft, oder die Instanz so bald wie möglich offline nehmen.

DIVD zufolge entdeckte die Organisation die Schwachstellen gemeinsam mit Merlon Security und informierte Zammad. Außerdem benachrichtigte sie Nutzer, von denen bekannt war, dass sie verwundbare Instanzen betreiben.

Was Administratoren jetzt vorrangig tun sollten

Zammad-Betreiber sollten die Empfehlung zum Upgrade als wichtigste Maßnahme behandeln. Systeme, die nicht kurzfristig auf Version 7 aktualisiert werden können, sollten nach Empfehlung von DIVD isoliert oder offline genommen werden, bis sie abgesichert sind.

Da der gemeldete Vorfall eine Sitzungsübernahme und die Ausführung von Code mit Root-Rechten umfasste, reicht es möglicherweise nicht aus, lediglich ein Passwort zurückzusetzen, wenn ein System bereits kompromittiert wurde. Administratoren sollten den Host und verbundene Dienste auf Anzeichen unbefugter Zugriffe, Privilege Escalation und Datenabrufe untersuchen.

Zu den sinnvollen Prüfpunkten zählen:

• Ungewöhnliche authentifizierte Sitzungen oder Änderungen am Sitzungsverhalten.
• Prozesse, die unter dem Zammad-Konto gestartet wurden und nicht zum normalen Anwendungsverhalten passen.
• Hinweise auf Befehle oder Prozesse, die mit Root-Rechten ausgeführt wurden.
• Verbindungen des Zammad-Hosts zu internen Diensten, auf die er normalerweise nicht zugreift.
• Ungewöhnliche ausgehende Datenübertragungen oder Zugriffe auf große Mengen von Ticket- und Dienstdaten.
• Änderungen an Konten, Berechtigungen oder Konfigurationen während verdächtiger Aktivitäten.

Dies sind allgemeine Untersuchungsschwerpunkte, die sich aus den von DIVD beschriebenen Auswirkungen ergeben, keine spezifischen Indikatoren für die Schwachstellen. Der zitierte Bericht enthält weder IP-Adressen noch Datei-Hashes, Domains, Log-Signaturen oder andere konkrete Indicators of Compromise.

Wenn möglich, sollten Verteidiger System-, Anwendungs-, Authentifizierungs- und Netzwerkprotokolle sichern, bevor sie ein verdächtiges System neu aufsetzen oder offline nehmen. Eine Netzwerksegmentierung zwischen dem Ticketsystem und sensiblen internen Diensten kann außerdem einschränken, worauf ein Angreifer nach einer ersten Kompromittierung zugreifen kann – wie der Vorfall bei DIVD zeigt.

Wichtige technische Fragen sind noch offen

Der Vorfall zeigt, dass die Auswirkungen schwerwiegend waren. Für eine umfassendere Risikobewertung fehlen jedoch wichtige Details. Der zitierte Bericht enthält weder einen CVSS-Score noch eine formelle Schweregradbewertung; auch die genau betroffenen Versionen werden nicht genannt.

Ebenso fehlt eine genaue Aufschlüsselung der verwundbaren und korrigierten Builds. Die öffentlich verfügbaren Informationen zeigen nicht, welche Requests für die Ausnutzung verwendet wurden, welche Zugriffsbedingungen erforderlich waren oder welche Spuren die Angriffskette hinterließ.

Der Bericht liefert auch keine Belege dafür, dass weitere Zammad-Kunden kompromittiert wurden. Bestätigt ist der hier beschriebene Vorfall bei DIVD sowie die Zuordnung des Angriffs zu den beiden Zero-Days durch die Organisation.

Bis weitere Erkenntnisse von DIVD und technische Informationen von Zammad vorliegen, ist die Handlungsempfehlung angesichts der Kombination aus Session Hijacking, Remote Code Execution und einer Privilege Escalation bis zu Root eindeutig: Auf Version 7 aktualisieren oder die exponierte Instanz außer Betrieb nehmen. Erst mit weiteren Informationen lässt sich der Kreis der betroffenen Nutzer genauer eingrenzen und eine präzise Erkennung unterstützen.