Zammad-Zero-Days: Einbruch bei DIVD, CISA-KEV seit 2. Oktober, Streit um die betroffenen Versionen
Am 21. September 2026 ist ein Angreifer über den eigenen Zammad-Helpdesk in das Netz des Dutch Institute for Vulnerability Disclosure (DIVD) eingedrungen. DIVD beschreibt im Fallbericht DIVD-2026-00014 zwei bis dahin unbekannte Lücken, die zusammen Session-Übernahme, Codeausführung als Benutzer zammad und die Rechteausweitung auf root erlaubten, laut DIVD „in Sekunden". Seit dem 2. Oktober stehen beide Lücken, CVE-2026-102489 und CVE-2026-102490, im KEV-Katalog der CISA; US-Bundesbehörden müssen bis zum 5. Oktober reagieren. Zammad 7.2.0 härtet die erste Lücke, für die zweite gibt es mit Stand 3. Oktober keinen bestätigten Fix.
Die Kette sieht nach Darstellung von DIVD so aus:
Was DIVD über den Einbruch schreibt
DIVD hat den Einbruch am 22. September bemerkt, den Zugriff auf alle Systeme im Rechenzentrum gesperrt und mit Merlon Security die Forensik begonnen. Laut Statement 4 vom 30. September konnte der Angreifer von root aus auf andere Dienste zugreifen und Daten abziehen; eine saubere Netzsegmentierung und das Eingreifen des eigenen Teams hätten ihn aufgehalten, bevor er tiefer ins Netz kam. Abgeflossen sind nach Statement 5 Daten von Freiwilligen, etwa DIVD-Mailadressen und möglicherweise Kontaktdaten. DIVD warnt deshalb vor Nachrichten, die sich als DIVD-Freiwillige ausgeben.
Den Angreifer stuft DIVD als KI-Agenten ein. Die Skripte enthielten Kommentare, in denen der Agent sein eigenes Vorgehen rechtfertigt und erklärt, warum das „kein Phishing" sei; ein menschlicher Angreifer würde sich das nach Ansicht von DIVD sparen. Der Angriff sei „laut und sehr unordentlich" gewesen. Belegt hat DIVD das mit zwei geschwärzten Screenshots. Die Einordnung als KI-Angriff ist die Aussage von DIVD, eine unabhängige Prüfung liegt nicht vor. BleepingComputer hat am 30. September darüber berichtet und gibt ebenfalls DIVD als Quelle an.
Welche Versionen betroffen sind, und laut wem
DIVD und Zammad sind sich über die Versionsbereiche nicht einig. Die Tabelle trennt die Angaben nach Quelle:
| Versionsbereich | CVE | Aussage | Laut |
|---|---|---|---|
6.3.0 bis 6.5.4 | CVE-2026-102489 | ausnutzbar, Codeausführung als zammad | DIVD-2026-00015 |
7.0.0 bis 7.1.3 | CVE-2026-102489 | Fehler im Code vorhanden, wegen der Umgebung nicht ausnutzbar | DIVD-2026-00015 |
6.5 und älter | CVE-2026-102489 | ausnutzbar, Versionen ohne Support | Zammad, 1. Oktober |
7.0 und neuer | CVE-2026-102489 | nicht betroffen, Code in 7.2.0 gehärtet | Zammad, 1. Oktober |
1.5.0 bis 7.1.0-alpha | CVE-2026-102490 | root aus dem Benutzer zammad | DIVD-2026-00015, Versionsfeld |
| alle bis zur neuesten Alpha | CVE-2026-102490 | root aus dem Benutzer zammad | DIVD-2026-00015, Zusammenfassung |
| offen | CVE-2026-102490 | Details erhalten, allein aus der Ferne nicht ausnutzbar, in Arbeit | Zammad, 1. Oktober abends |
Die beiden DIVD-Angaben zur Rechteausweitung widersprechen sich: Das Versionsfeld endet bei 7.1.0-alpha, die Zusammenfassung spricht von allen Versionen bis zur neuesten Alpha. Neueste Alpha im Repository ist seit dem Release von 7.2.0 am 23. September die 7.3.0-alpha. Wer 7.2.0 betreibt, kann sich deshalb für CVE-2026-102490 nicht auf die engere Spanne verlassen. Das Feld „Patch status" auf der DIVD-Seite steht auf „Available"; eine Zammad-Sicherheitsmeldung zu einer der beiden CVEs gibt es in den GitHub-Advisories mit Stand 3. Oktober nicht, die jüngsten Einträge sind vom 25. August. runZero bewertet die Lücken mit CVSS 8,7 und 8,5 und vermerkt, dass der Hersteller die Angaben zu CVE-2026-102490 bestreitet.
Der Streit um die Offenlegung
Laut der DIVD-Zeitleiste ging die Meldung am 24. September an Zammad. Am 26. September hat DIVD öffentlich erreichbare Zammad-Instanzen gescannt, eine begrenzte Offenlegung beider CVEs veröffentlicht und begonnen, Betreiber anfälliger Instanzen zu benachrichtigen.
| Datum | Ereignis | Quelle |
|---|---|---|
| August 2026 | erste Meldung zu CVE-2026-102489 bei Zammad | Zammad |
| 21. September | erster Zugriff des Angreifers bei DIVD | DIVD-2026-00014 |
| 23. September | Zammad 7.2.0 veröffentlicht | Git-Tag |
| 24. September | Meldung beider Lücken an Zammad | DIVD-2026-00015 |
| 26. September | Scan, begrenzte Offenlegung, Benachrichtigungen | DIVD-2026-00015 |
| 30. September | DIVD nennt Zammad öffentlich als Einfallstor | DIVD-2026-00014 |
| 1. Oktober | Statement von Zammad, abends Details zu 102490 erhalten | Zammad |
| 2. Oktober | Aufnahme beider CVEs in den KEV-Katalog, Frist 5. Oktober | CISA |
Zammad schreibt im Statement vom 1. Oktober, man habe zu CVE-2026-102490 bis dahin keine technischen Details erhalten und könne eine Behauptung, die man nicht gezeigt bekommen habe, nicht prüfen. Eine CVE für eine Lücke zu veröffentlichen, über die der Hersteller nicht informiert war, hält Zammad nicht für einen verantwortungsvollen Umgang. Am Abend desselben Tages kam der Nachtrag: Die Details sind da, die Lücke sei allein aus der Ferne nicht ausnutzbar, ein Angreifer brauche bereits Zugang zum Server. Bei DIVD war genau dieser Zugang durch CVE-2026-102489 gegeben.
Die CISA führt beide Einträge mit forensicTriage: Yes im KEV-Katalog. Für US-Bundesbehörden heißt das nach der Richtlinie BOD 26-04 auch, vor dem Patch zu prüfen, ob das System bereits kompromittiert ist. Für Unternehmen außerhalb der US-Bundesverwaltung ist das nicht verbindlich, die Reihenfolge passt aber auch dort.
Was jetzt zu tun ist
Unser Zammad lief bis zum Abend des 3. Oktober auf 7.0.0-9 und läuft seitdem auf 7.2.0. Gegen CVE-2026-102490 hilft das nach heutigem Stand nicht, dafür gibt es noch keinen bestätigten Fix. Für eigene Instanzen gilt dieselbe Reihenfolge, wie wir sie in Patch-Management für KMU beschrieben haben, hier mit fester Priorität:
- Version feststellen. Alles bis 6.5 ist ohne Support und nach beiden Quellen über CVE-2026-102489 von außen angreifbar. Solche Instanzen gehören sofort aktualisiert oder vom Netz genommen, wie DIVD es empfiehlt.
- Auf Zammad 7.2.0 aktualisieren, die aktuelle stabile Version.
- Logs prüfen. DIVD stellt ein Prüfskript für die Zammad-Logs bereit, es sucht standardmäßig unter
/var/log/zammadund/var/log/nginxund liest auch gepackte Dateien. Bei Docker-Installationen liegen die Logs woanders, die Pfade lassen sich als Argument übergeben. - Erreichbarkeit einschränken. Ein Helpdesk muss für Kunden erreichbar sein, die Agenten-Oberfläche oft nicht. Wo es geht, steht die Anmeldung für Agenten hinter VPN oder einer IP-Freigabe.
- Den Zammad-Server so trennen, dass root dort keinen Weg zu anderen Diensten öffnet. Bei DIVD hat genau das den Schaden begrenzt.
- Die GitHub-Advisories von Zammad beobachten und den Fix für CVE-2026-102490 einspielen, sobald er erscheint.
Wer Zammad erst einführt, findet Aufbau und Betrieb im Beitrag zum Zammad-Helpdesk. Offen bleibt, welche Versionen CVE-2026-102490 tatsächlich betrifft und ob 7.2.0 dazugehört; das klärt erst die Meldung des Herstellers.
Weiterführende Quellen
- DIVD-2026-00014, Fallbericht zum Einbruch bei DIVD mit fünf Statements und Zeitleiste
- DIVD-2026-00015, Fallakte zu CVE-2026-102489 und CVE-2026-102490 mit Versionsbereichen
- DIVD-Prüfskript für Zammad-Logs auf Spuren von CVE-2026-102489
- Zammad-Statement vom 1. Oktober 2026 mit Nachtrag zu CVE-2026-102490
- CISA-Meldung vom 2. Oktober 2026 zur Aufnahme in den KEV-Katalog
- CISA Known Exploited Vulnerabilities Catalog
- Zammad Security Advisories auf GitHub
- Zammad-Tags auf GitHub, darunter 7.2.0 und 7.3.0-alpha
- runZero, Zusammenfassung mit CVSS-Werten
- BleepingComputer, Bericht vom 30. September 2026
Ist Zammad 7.x betroffen?+
Für CVE-2026-102489 sagen DIVD und Zammad übereinstimmend, dass der Fehler ab 7.0 nicht ausnutzbar ist; DIVD sieht den Code-Fehler bis 7.1.3 noch vorhanden, Zammad hat ihn in 7.2.0 gehärtet. Für CVE-2026-102490 nennt DIVD 1.5.0 bis 7.1.0-alpha und schreibt zugleich von allen Versionen bis zur neuesten Alpha. Zammad hatte am 1. Oktober abends erst die Details erhalten und bestätigt noch keinen Versionsbereich.
Reicht das Update auf 7.2.0?+
Es schließt den bekannten Weg über CVE-2026-102489, über den der Angreifer bei DIVD von außen hereinkam. Die Rechteausweitung von zammad auf root ist laut Hersteller allein aus der Ferne nicht ausnutzbar, ein Fix dafür ist aber noch nicht veröffentlicht. Nach dem Update gehören die Logs geprüft und der Server so abgeschottet, dass ein root-Zugriff dort nicht weiterkommt.
Stammt der Angriff wirklich von einem KI-Agenten?+
Das ist die Einschätzung von DIVD. Sie stützt sich auf Kommentare in den Skripten des Angreifers, in denen sich der Agent sein Vorgehen selbst rechtfertigt, und auf das schnelle, unsaubere Vorgehen. DIVD hat dazu zwei geschwärzte Screenshots veröffentlicht, eine unabhängige Bestätigung gibt es bisher nicht.
senn-tech