Ivanti EPMM, Sentry und Connector: Hinweise zur Linux-Sicherheitslücke CVE-2026-98432

Die kritische Sicherheitslücke CVE-2026-98432 im Linux-Kernel betrifft die Verarbeitung eingehender IPv4-TCP-Verbindungen. Ivanti untersucht derzeit, welche Auswirkungen sie auf EPMM (Core), Sentry und Connector hat. Bis zur Bereitstellung entsprechender Produktupdates empfiehlt der Hersteller, eine vorübergehende Schutzmaßnahme zu prüfen.

Für Unternehmen bedeutet das: Erfasst eure eingesetzten Systeme, prüft deren Erreichbarkeit und stimmt geeignete Gegenmaßnahmen ab. Eine pauschale Aussage, dass sämtliche Versionen der drei Produkte betroffen sind, lässt sich aus der aktuellen Ivanti-Meldung nicht ableiten. Quelle: Ivanti

Was hinter der Sicherheitslücke steckt

Beim Aufbau von TCP-Verbindungen kann der Linux-Kernel unter bestimmten zeitlichen Bedingungen auf bereits freigegebenen Speicher zugreifen. Ein solcher „Use-after-free“-Fehler kann Systemabstürze und Speicherbeschädigungen verursachen und unter bestimmten Voraussetzungen die Ausführung von Schadcode ermöglichen. Die Schwachstelle wird mit CVSS 9,8 von 10 Punkten als kritisch eingestuft. Quellen: Red Hat, Ubuntu

Ein Angreifer benötigt dafür weder Zugangsdaten noch die Mitwirkung eines Benutzers. Für den beschriebenen Angriffsweg müssen präparierte IPv4-TCP-Pakete mit IP-Optionen einen erreichbaren TCP-Dienst auf einem verwundbaren System erreichen. Öffentlich erreichbare Systeme verdienen daher besondere Aufmerksamkeit. Auch Zugriffe aus nicht vertrauenswürdigen internen Netzen sollten berücksichtigt werden. Quellen: Red Hat, AWS

AWS berichtet bereits über demonstrierte Codeausführung auf Linux-Systemen mit einem Multipath-TCP-Listener. Auch ohne Multipath TCP lässt sich eine Gefährdung nicht ausschließen, da der zugrunde liegende Fehler die allgemeine IPv4-TCP-Verarbeitung betrifft. Der demonstrierte Angriff ist jedoch kein Nachweis einer erfolgreichen Ausnutzung auf Ivanti-Appliances. AWS nennt in seiner Meldung vom 10. November keine Hinweise auf eine tatsächliche Ausnutzung. Das ist keine Entwarnung für ungepatchte Systeme. Quellen: AWS, Red Hat

Welche Ivanti-Produkte und Versionen geprüft werden

Ivanti nennt EPMM (Core), Sentry und Connector als Linux-basierte Produkte, deren Betroffenheit untersucht wird. Der am 11. November geprüfte Supportartikel enthält noch keine konkreten betroffenen Versionsbereiche, korrigierten Produktversionen oder verbindlichen Veröffentlichungstermine.

Ivanti arbeitet an einer Aktualisierung des Kernels. Da solche Änderungen die Funktionen der Produkte beeinflussen können, sind zusätzliche Tests und eine Validierung erforderlich. Quelle: Ivanti

Für den Betrieb ist insbesondere die Verfügbarkeit relevant: Ein Ausfall einer betroffenen Appliance könnte je nach Rolle die Geräteverwaltung oder angebundene Dienste beeinträchtigen. Welche Auswirkungen im Einzelfall möglich sind, hängt von der eingesetzten Umgebung ab.

Welcher Workaround verfügbar ist

Ivanti verweist vorübergehend auf eine von Ubuntu beschriebene Firewall-Regel. Sie verwirft eingehende IPv4-TCP-Pakete, die IP-Optionen enthalten. Dabei handelt es sich um Optionen im IP-Header, nicht um übliche TCP-Optionen wie Zeitstempel oder Window Scaling.

Die Regel reduziert das Risiko, ersetzt aber keinen Kernel-Patch und verhindert laut Ubuntu eine Ausnutzung nicht vollständig. Zudem können legitime Verbindungen unterbrochen werden, wenn sie IP-Optionen benötigen. Ivanti empfiehlt deshalb, die Maßnahme zunächst auf einem Nicht-Produktivsystem zu testen. Quellen: Ivanti, Ubuntu

Was ihr jetzt tun solltet

• Bestand und Erreichbarkeit prüfen: Erfasst Produktversionen und Patchstände eurer EPMM-, Sentry- und Connector-Systeme. Prüft, welche Dienste aus dem Internet oder anderen nicht vertrauenswürdigen Netzen erreichbar sind. Beschränkt insbesondere administrative Zugänge auf die erforderlichen vertrauenswürdigen Netze.
• Gegenmaßnahmen abgestimmt umsetzen: Bewertet die Filterregel mit euren Administratoren oder dem Support. Sichert zuvor die bestehende Konfiguration und plant Funktionstests sowie einen Rückweg ein.
• Produktupdates nachverfolgen: Prüft den Ivanti-Supportartikel regelmäßig und plant freigegebene Updates einschließlich erforderlicher Neustarts ein. Installiert auf den Appliances keine allgemeinen Distributions-Kernelpakete ohne passende Ivanti-Freigabe.

Technische Ergänzung: Filterregel auf EPMM oder Sentry einrichten

Die folgende Vorgehensweise basiert auf unserer internen Anleitung und der von Ivanti verlinkten Ubuntu-Mitigation. Sie richtet sich an erfahrene Administratoren. Die Eignung für die jeweilige Produktversion und Firewall-Konfiguration muss vor der Anwendung geprüft werden. Für Connector ist der hier beschriebene Shell-Zugang nicht bestätigt.

Testet die Umsetzung zunächst außerhalb der Produktion. Haltet für Änderungen an der Firewall einen unabhängigen Konsolenzugang bereit, damit ihr bei Verbindungsproblemen reagieren könnt.

1. Linux-Shell öffnen

Voraussetzung ist ein vorbereiteter Supportzugang mit gültigem One-Time-Password. Verbindet euch per SSH mit EPMM oder Sentry und führt diese Befehle einzeln aus:

enable
configure terminal
service support
end
ssh misupport localhost

Meldet euch mit dem zuvor für den Supportzugang generierten One-Time-Password an. Falls eine Abfrage zum SSH-Fingerprint erscheint, prüft diesen vor der Bestätigung.

Wechselt anschließend in eine Root-Shell:

sudo -i

2. Regeldatei erstellen und kontrollieren

Prüft zuvor, ob die Datei oder eine gleichnamige nftables-Tabelle bereits existiert. Der folgende Befehl überschreibt eine vorhandene Datei dieses Namens. Bei einer bereits eingerichteten Mitigation ist zunächst deren Zustand zu prüfen, statt die Schritte erneut auszuführen.

cat > /etc/cve-2026-98432.nft <<'EOF'
table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}
EOF

Kontrolliert den gespeicherten Inhalt:

cat /etc/cve-2026-98432.nft

Die Ausgabe muss dem Inhalt zwischen den beiden EOF-Markierungen entsprechen.

3. Syntax prüfen und Regel aktivieren

nft -c -f /etc/cve-2026-98432.nft && \
nft -f /etc/cve-2026-98432.nft

Der erste Befehl prüft die Syntax. Nur bei erfolgreicher Prüfung lädt der zweite Befehl die Regel. Ab diesem Moment verändert sie die laufende Paketfilterung. Eine erfolgreiche Syntaxprüfung ersetzt keinen Funktionstest.

Kontrolliert anschließend die geladene Tabelle:

nft list table inet cve_2026_98432

Testet danach den administrativen Zugriff und die für eure Umgebung relevanten Geräte- und Dienstverbindungen. Der Paket-Zähler der Regel zeigt verworfene Pakete an, ist allein aber kein Nachweis eines Angriffs.

4. Laden nach einem Neustart vorbereiten

Dieser Schritt setzt voraus, dass /etc/nftables.conf die Firewall-Konfiguration verwaltet und keine konkurrierende Verwaltung durch beispielsweise UFW oder firewalld erfolgt. Prüft außerdem die produktspezifischen Vorgaben der Appliance. Quelle: Ubuntu

Sichert die bestehende Konfiguration. Fügt die folgende Include-Zeile nur einmal hinzu. Ist sie bereits vorhanden, überspringt den ersten Befehl.

echo 'include "/etc/cve-2026-98432.nft"' | tee -a /etc/nftables.conf
nft -c -f /etc/nftables.conf && systemctl enable nftables.service

Die Aktivierung des Dienstes allein bestätigt noch nicht, dass die Regel nach einem Neustart korrekt geladen wird. Prüft dies im geplanten Wartungsfenster und wiederholt anschließend die Funktionstests. Bei Fehlermeldungen sollte die Ursache geklärt werden, bevor ihr fortfahrt.

5. Änderung dokumentieren und Nachkontrolle planen

Dokumentiert die eingerichtete Regel, die Prüfergebnisse und den Rückweg. Für eine Rücknahme müssen sowohl die aktive Tabelle als auch ihr automatisches Laden entfernt werden. Dabei entfällt die zusätzliche Filterwirkung.

Beendet den temporären Supportzugang nach Abschluss gemäß den Vorgaben für eure Produktversion. Prüft nach einem Produktupdate erneut, ob die Mitigation noch benötigt wird und ob die Firewall-Konfiguration unverändert wirksam ist.

Wie es weitergeht

Die endgültige Bewertung der Ivanti-Produkte und die dazugehörigen Fixversionen stehen im geprüften Herstellerartikel noch aus. Bis dahin sind eine Prüfung der eigenen Umgebung und abgestimmte Übergangsmaßnahmen sinnvoll. Der Workaround sollte dabei als vorübergehende Risikoreduzierung behandelt werden.

Stand: 11. November 2026.

Text: anyplace IT GmbH / Bildnachweis: anyplace IT GmbH (erstellt mit KI).