Zammad-Lücken CVE-2026-102489 und 102490: jetzt absichern

Seit dem 2. Oktober 2026 stehen zwei Zammad-Lücken im Katalog aktiv ausgenutzter Schwachstellen der US-Behörde CISA; das BSI stuft sie in seiner Warnung als kritisch ein. CVE-2026-102489 führt auf Zammad bis 6.5.4 von einer übernommenen Sitzung zur Codeausführung als Benutzer zammad. CVE-2026-102490 hebt genau diesen Benutzer auf root, und dafür gibt es laut Zammad-Advisory noch keinen Fix (Stand 8. Oktober 2026). Wer Zammad selbst betreibt, sollte jetzt Spuren sichern, auf 7.2.1 aktualisieren und den Server abschotten. Bei Paket-Installationen kommt eine Falle dazu: Die alte Paketquelle liefert keine Version ab 7.1 mehr aus, und apt upgrade meldet das nicht.

Zwei Lücken, eine Angriffskette

Das niederländische DIVD hat die Lücken analysiert, nachdem Angreifer sie am 21. September 2026 für einen Einbruch bei DIVD selbst genutzt hatten. Laut DIVD ging die Meldung am 24. September an Zammad, am 5. Oktober folgte das Zammad-Advisory, am 6. Oktober Version 7.2.1.

CVE-2026-102489: übernommene Sitzung, fremder Code

Laut NVD sind die Versionen 6.3.0 bis 6.5.4 anfällig für eine Session-Übernahme, die in Codeausführung als Benutzer zammad mündet. Der Fehler steckt auch in 7.0.0 bis 7.1.2, ist dort aber wegen Änderungen im darunterliegenden Framework nicht ausnutzbar. Zammad bestätigt: Ausnutzbar sind nur 6.5 und ältere Versionen, und die bekommen keine Sicherheitsupdates mehr. Die Codeänderungen stecken in 7.2.0.

CVE-2026-102490: vom Dienstkonto zu root

Die zweite Lücke betrifft laut NVD alle Versionen bis zur aktuellen Alpha. Zammad stuft sie als lokale Rechteausweitung ein, die sich allein nicht aus der Ferne ausnutzen lässt, und verweist auf eine bestätigte Schwachstelle bei packager.io, dem Dienst, über den die Zammad-Pakete gebaut werden. Gefährlich ist die Kombination: Wer über die erste Lücke Code als zammad ausführt, hat genau den lokalen Zugang, den die zweite voraussetzt.

+----------------------------------------------------------+
| 1. Angriff ueber das Netz                                |
|    |                                                     |
|    |  CVE-2026-102489 (6.3.0 bis 6.5.4)                  |
|    |                                                     |
| 2. Code laeuft als Benutzer "zammad"                     |
|    |                                                     |
|    |  CVE-2026-102490 (alle Versionen)                   |
|    |                                                     |
| 3. root auf dem Server                                   |
+----------------------------------------------------------+

	CVE-2026-102489	CVE-2026-102490
Wirkung	Codeausführung als zammad	Rechteausweitung zu root
Voraussetzung	Zugriff über das Netz	lokaler Zugang zum Server
Ausnutzbar	6.3.0 bis 6.5.4	alle Versionen
Fix	Codeänderungen ab 7.2.0	keiner (Stand 8. Oktober 2026)
CVSS 4.0 (DIVD)	8.7, in der Kette 9.4	8.5, in der Kette 9.4
CVSS 3.1 (NVD)	9.8	9.8

Bestandsaufnahme: Version und Paketquelle

Welche Version läuft?

Am schnellsten zeigt es der Admin-Bereich unter System > Version. Auf der Kommandozeile helfen Paketmanager und Docker:

# Paket-Installation unter Debian oder Ubuntu
apt-cache policy zammad
# Paket-Installation unter RHEL oder SLES
rpm -q zammad
# Docker Compose: Tags der laufenden Images
docker compose images

Woher kommen die Pakete?

Seit Zammad 7 liegen die Pakete unter einer neuen Adresse, und laut Release Notes zu 7.1 liefern die alten Repositories nur Versionen vor 7.1 aus, bis sie abgeschaltet werden. Wer seinen Server vor dem 26. März 2026 nach der damaligen Anleitung eingerichtet hat, bezieht die Pakete wahrscheinlich noch von dl.packager.io. Das prüfen Sie so:

grep -r "packager.io" /etc/apt/sources.list.d/ /etc/yum.repos.d/ /etc/zypp/repos.d/ 2>/dev/null

Den Unterschied zeigt eine Gegenprobe vom 8. Oktober 2026 in einem frischen Ubuntu-24.04-Container, einmal mit jeder Quelle:

# alte Quelle: dl.packager.io
$ apt-cache policy zammad
zammad:
  Installed: (none)
  Candidate: 7.0.2-1781669454.9dc15acf.noble

# neue Quelle: go.packager.io
$ apt-cache policy zammad
zammad:
  Installed: (none)
  Candidate: 7.2.1-1791411395.f5b1a3e.ubuntu24

	alte Quelle	neue Quelle
Host	dl.packager.io	go.packager.io
Release-Datei (Ubuntu 24.04) zum Messzeitpunkt	25.06.2026	07.10.2026
neueste Version	7.0.2	7.2.1
Signaturschlüssel	B6D583CCBD33EEB8	54109AEE4C3EC117

Ein Server an der alten Quelle hält sich mit 7.0.2 also für aktuell. CVE-2026-102489 ist dort zwar praktisch nicht ausnutzbar, offen bleiben aber die 27 Lücken, die Zammad mit 7.2.1 laut seinen GitHub-Advisories geschlossen hat, zwei davon kritisch. Ein künftiger Fix für CVE-2026-102490 kommt über diese Quelle ebenfalls nicht an.

Erst Spuren sichern, dann aktualisieren

Warum nicht einfach sofort updaten?

Der naheliegende Reflex lautet: Update einspielen, weiterarbeiten. Für Instanzen, die mit 6.5.x oder älter aus dem Internet erreichbar waren, ist diese Reihenfolge falsch, aus drei Gründen. Erstens tauscht ein Update den Code unter /opt/zammad aus, entfernt aber nichts, was ein Angreifer mit root-Rechten anderswo abgelegt hat. Zweitens ersetzt docker compose up -d mit neuem Image die Container, und deren Logs verschwinden mit ihnen; in einem Test mit einem Wegwerf-Stack lieferte docker compose logs danach nur noch die Zeilen des neuen Containers. Drittens löscht logrotate bei Paket-Installationen laut Zammad-Doku alte Logs nach 14 Tagen, am 8. Oktober reichen sie also nur noch bis etwa 24. September zurück. Deshalb gilt: Zammad sofort vom Netz nehmen (Firewall oder Reverse Proxy), Logs und Backup sichern, prüfen, erst dann aktualisieren.

Logs mit dem DIVD-Prüfskript durchsuchen

DIVD stellt auf seiner Fallseite ein Skript bereit, das Zammad- und nginx-Logs (auch gepackte) nach ERROR-Zeilen mit Sitzungsdaten durchsucht. Version 2 des Skripts hat allerdings Windows-Zeilenenden, und unter dash, dem /bin/sh von Debian und Ubuntu, bricht es sofort ab:

$ sh cve-2026-102489_ioc_check_script_v2.sh
cve-2026-102489_ioc_check_script_v2.sh: 7: set: Illegal option -

Hinter dem Bindestrich steht ein unsichtbares Wagenrücklaufzeichen, aus set -u wird set -u\r. Außerdem endet das Skript immer mit Exit-Code 0, auch wenn es keine einzige Logdatei gefunden hat. Entfernen Sie deshalb zuerst die Wagenrücklaufzeichen und werten Sie die Ausgabe aus, nicht den Exit-Code:

sed 's/\r$//' cve-2026-102489_ioc_check_script_v2.sh > zammad-ioc-check.sh
# Paket-Installation: beide moeglichen Log-Pfade und nginx angeben
sudo sh zammad-ioc-check.sh /var/log/zammad /opt/zammad/log /var/log/nginx
# Docker Compose: Logs zuerst in eine Datei exportieren
docker compose logs --no-color > zammad-docker.log
sh zammad-ioc-check.sh zammad-docker.log

Meldet das Skript error: no log files found, stimmt der Pfad nicht; eine Entwarnung ist das nicht. Es sucht außerdem nur nach Spuren von CVE-2026-102489, Indikatoren für die Root-Eskalation enthält es keine.

Treffer: neu aufsetzen statt reparieren

Findet die Prüfung etwas, hilft kein Update mehr: Bei offener Root-Lücke ist dem Server nicht mehr zu trauen. Stellen Sie das Backup auf einem neuen Server wieder her (laut Zammad-Doku am einfachsten mit derselben Version wie zuvor), aktualisieren Sie dort auf 7.2.1, prüfen Sie die Admin-Konten und tauschen Sie alle Zugangsdaten: E-Mail-Kanäle, API-Tokens, Admin-Kennwörter. Was ein Tag ohne Helpdesk kostet, beziffert der Ausfallkosten-Rechner.

Update auf 7.2.1 für Paket und Docker Compose

Was vor dem Sprung von 6.5 stimmen muss

Zammad rät, beim Update keine Hauptversion auszulassen; von 6.5 auf 7.2.1 lassen Sie keine aus. Vorher muss aber Folgendes stimmen:

Komponente	Anforderung für 7.2.1
Datenbank	PostgreSQL 15 oder neuer, MySQL und MariaDB vorher migrieren
Elasticsearch	8.15 oder neuer, aber unter 10
Redis	7 oder neuer
nginx	proxy_http_version 1.1; auch in der Haupt-location

Wer noch MySQL nutzt, kann nicht sofort auf 7 wechseln; dann bleibt die zweite Option, die DIVD nennt: die Instanz offline nehmen.

Paket-Installation: Quelle wechseln, dann aktualisieren

Das Backup-Skript braucht einmalig eine Konfiguration (config.dist in /opt/zammad/contrib/backup/ zu config umbenennen), das Ergebnis gehört danach vom Server weg, etwa verschlüsselt mit Restic nach S3 oder Backblaze B2. Der Quellenwechsel folgt der Zammad-Doku, hier für Ubuntu 24.04:

sudo systemctl stop zammad
# Logs separat sichern, fehlende Pfade werden uebersprungen
sudo tar czf /root/zammad-logs-pre-update.tar.gz --ignore-failed-read /var/log/zammad /opt/zammad/log /var/log/nginx
sudo /opt/zammad/contrib/backup/zammad_backup.sh
# alte Quelle und alten Schluessel entfernen (Dateinamen liefert das grep oben)
sudo rm /etc/apt/sources.list.d/zammad.sources
sudo rm /etc/apt/keyrings/pkgr-zammad.gpg
# neuen Schluessel und neue Quelle einrichten
sudo curl -fsSL "https://go.packager.io/srv/deb/zammad/zammad/gpg-key.gpg" \
  -o /usr/share/keyrings/zammad.gpg && sudo chmod 644 /usr/share/keyrings/zammad.gpg
sudo curl -fsSL "https://go.packager.io/srv/zammad/zammad/stable/installer/ubuntu/24.04.list" \
  -o /etc/apt/sources.list.d/zammad.list
sudo apt update
sudo apt-mark unhold zammad
sudo apt upgrade zammad

Wer nur dl. durch go. ersetzt und den alten Schlüssel behält, scheitert beim apt update:

Err:1 https://go.packager.io/srv/deb/zammad/zammad/stable/ubuntu 24.04 InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 54109AEE4C3EC117
E: The repository 'https://go.packager.io/srv/deb/zammad/zammad/stable/ubuntu 24.04 InRelease' is not signed.

Die Ursache: Die neue Quelle ist mit einem anderen Schlüssel signiert (54109AEE4C3EC117) als die alte (B6D583CCBD33EEB8). Ohne den neuen Schlüssel lehnt apt die Quelle ab.

Docker Compose: VERSION in der .env prüfen

Die Compose-Datei enthält image: ${IMAGE_REPO:-ghcr.io/zammad/zammad}:${VERSION:-7.2.1-0000}. Steht in Ihrer .env noch ein Wert wie VERSION=6.5, bleibt der Stack nach git pull verwundbar; das Tag 6.5 zeigte am 8. Oktober sogar nur auf 6.5.2-94. Wer von einem älteren Stack kommt, findet in den Release Notes des Compose-Stacks diese Stolpersteine:

Stack-Version	Änderung
v14.0.0	neues Elasticsearch-Image, Rechte im Volume einmalig korrigieren
v15.0.0	Elasticsearch 9 und Redis 8, CPU mit SSE4.2 nötig
v16.0.0	kein automatisches Backup mehr beim Neustart
v17.0.0	Docker Compose 2.23.1 oder neuer

cd zammad-docker-compose
grep '^VERSION' .env
# Logs und Backup sichern, bevor die Container ersetzt werden
docker compose logs --no-color > zammad-logs-pre-update.log
docker compose run --rm --env BACKUP_ONCE=true --env BACKUP_ON_START=true zammad-backup
git pull
docker compose pull
# nur beim Sprung von einem Stack vor v14.0.0 (neues Elasticsearch-Image)
docker compose run -it -u0 zammad-elasticsearch chown elasticsearch -Rv /usr/share/elasticsearch/data
docker compose up -d
docker compose images

Vor dem git pull läuft noch das alte Image. Images der Reihen 6.5 und 7.0 sowie frühe 7.1-Builds kennen BACKUP_ONCE nicht: Sie sichern sofort (frühe 7.1-Builds nur dank BACKUP_ON_START=true) und warten danach auf den nächsten planmäßigen Lauf. Brechen Sie den Befehl nach backup finished :) mit Strg+C ab; das Backup bleibt im Volume des Backup-Containers.

Wer VERSION fest setzt, ist laut .env.dist selbst für Patch-Updates zuständig; neue Tags meldet zum Beispiel Diun statt Watchtower.

Nach dem Update: FQDN und Suchindex

7.2.1 behebt unter anderem GHSA-23hj-h8w6-rgm3: Skripte im Browser konnten die Sitzungs-ID auslesen. Seitdem müssen die Einstellungen http_type und fqdn zur aufgerufenen URL passen; bei einem Nutzer im Zammad-Forum ließen sich sonst keine Tickets mehr speichern. Prüfen Sie beide Werte und bauen Sie den Suchindex neu auf, wie es die Breaking Changes zu 7.0 und 7.2 verlangen:

# Paket-Installation
zammad run rails r "p Setting.get('fqdn'); p Setting.get('http_type')"
zammad run rake zammad:searchindex:rebuild
# Docker Compose
docker compose run --rm zammad-railsserver bundle exec rails r "p Setting.get('fqdn'); p Setting.get('http_type')"
docker compose run --rm zammad-railsserver bundle exec rake zammad:searchindex:rebuild

CVE-2026-102490 eindämmen, solange der Fix fehlt

Wer kommt an eine Shell?

Zammad empfiehlt, den Zugang zum Server auf vertrauenswürdige Administratoren zu beschränken. Prüfen Sie, welche Konten eine Login-Shell haben, wer sudo darf und wer sich zuletzt angemeldet hat:

getent passwd | awk -F: '$7 !~ /(nologin|false)$/ {print $1": "$7}'
# RHEL: Gruppe wheel statt sudo
getent group sudo
last -n 20

SSH gehört nicht ins offene Internet; ein WireGuard-Tunnel zwischen Admin-Rechner und Server schließt den Port nach außen.

Sitzungen, Tokens und Zwei-Faktor

Nach einer Lücke, über die sich Sitzungen übernehmen ließen, sollten alle Sitzungen enden. Der Wartungsmodus (System > Maintenance) meldet laut Doku Agenten und Kunden ab. Admin-Sitzungen bleiben davon unberührt, die löschen Sie unter System > Sessions einzeln. Schalten Sie unter System > API den Token-Zugriff aus, funktionieren alle persönlichen Access-Tokens nicht mehr, solange der Schalter aus ist (gelöscht werden sie nicht); OAuth2-Tokens betrifft das nicht. Erzwingen Sie danach Zwei-Faktor-Authentifizierung über die Einstellung „Enforced for user roles“. Verlässlich ist das erst ab 7.2.1: Bis 7.2.0 ließ sich die Zwei-Faktor-Prüfung laut GHSA-f3qr-94c2-7mx2 über den E-Mail-Verifizierungsablauf umgehen.

Kurz beantwortet: Fragen zu den Zammad-Lücken

Ist Zammad 7.0 oder 7.1 noch gefährdet?

Durch CVE-2026-102489 laut Zammad und NVD praktisch nicht. CVE-2026-102490 betrifft aber alle Versionen, und alle 27 mit 7.2.1 geschlossenen Lücken betreffen auch 7.0 und 7.1. Ziel ist deshalb 7.2.1.

Mein Scanner meldet 7.2.1 als nicht betroffen. Stimmt das?

Für CVE-2026-102490 nicht. Die NVD-Beschreibung nennt alle Versionen, die maschinenlesbare Versionsangabe (CPE) endet aber vor 7.1.0. Scanner, die nur die CPE-Daten auswerten, melden 7.1 und neuer deshalb als sauber, obwohl es keinen Fix gibt.

Schützt Docker vor der Root-Eskalation?

Belegen lässt sich das nicht: Advisory und NVD-Beschreibung unterscheiden nicht nach Installationsart, die NVD-Konfiguration führt Docker sogar als Plattform. Dass das Image 7.2.1 laut seiner Konfiguration mit der UID 1000 statt als root läuft, ist keine Entwarnung.

Muss ich einen Vorfall melden?

Wenn Angreifer an Tickets gekommen sind, betrifft das in aller Regel personenbezogene Daten. Ob eine Meldepflicht nach DSGVO besteht, klären Sie mit Ihrem Datenschutzbeauftragten. Bei Analyse und sauberem Neuaufbau unterstützt Sie unser IT-Support für KMU.

Fix-Stand verfolgen: Quellen und Doku

Advisories und Warnungen

Den Fix-Stand von CVE-2026-102490 dokumentiert das Zammad-Advisory, die mit 7.2.1 geschlossenen Lücken stehen in den GitHub-Advisories von Zammad. Dazu kommen die NVD-Einträge zu CVE-2026-102489 und CVE-2026-102490, der CISA-Hinweis vom 2. Oktober, die BSI-Warnung WID-SEC-2026-3694 und die DIVD-Fallseite mit dem Prüfskript. Ein ähnliches Vorgehen für einen Webserver zeigt der Beitrag zur nginx-Lücke CVE-2026-42945.

Zammad-Dokumentation

Für die Umsetzung maßgeblich sind Updating Zammad, Host Upgrade and Repository Migration, die Software-Anforderungen und Backup and Restore für Docker Compose.