Ivanti Connect Secure-Schwachstelle löst CISA-Warnung aus, doch Patchen allein reicht nicht

Ivanti steht vor einer Notfallreaktion, nachdem Angreifer noch vor der Offenlegung am 13. Oktober eine Schwachstelle in Ivanti Connect Secure gegen vollständig gepatchte Appliances ausgenutzt hatten. CISA nahm CVE-2026-104935 noch am selben Tag in seinen Katalog bekannter aktiv ausgenutzter Schwachstellen auf. Die Lücke erlaubt es einem entfernten Angreifer, die Authentifizierung zu umgehen und ohne Nutzerinteraktion beliebige Befehle auszuführen.

Die unmittelbare Anweisung ist einfach: Ivantis korrigierte Version installieren. Schwieriger ist die Frage, ob Angreifer bereits eingedrungen sind, Zugangsdaten gestohlen und die offensichtlichsten Spuren beseitigt haben. Ermittler stellten fest, dass der beobachtete Akteur Appliances wiederholt ausnutzte, anstatt eine herkömmliche Backdoor zu installieren.

Dieses Verhalten stellt die vertraute Strategie aus Patchen und Scannen infrage. Ein Patch schließt den offengelegten Einstiegspunkt, widerruft jedoch keine gestohlenen Geheimnisse und beweist nicht, dass die Appliance zuvor sauber war. Bei exponierten VPN-Gateways erfordert die Behebung nun sowohl Softwarewartung als auch eine Incident-Untersuchung.

CISA macht die Ivanti Connect Secure-Schwachstelle zum Notfall

Die Warnung von CISA macht CVE-2026-104935 aus einer theoretischen Softwareschwachstelle zu einer bestätigten Priorität für die Incident Response.

Die Bundeswarnung der Behörde vom 13. Oktober besagt, dass Bedrohungsakteure die Schwachstelle für den Diebstahl von Zugangsdaten und die Exfiltration von Daten ausnutzen. CISA nahm die Lücke außerdem in seinen Katalog Known Exploited Vulnerabilities auf, der üblicherweise KEV genannt wird.

Ein KEV-Eintrag hat mehr operative Bedeutung als eine gewöhnliche Schwachstellenmeldung. Er bedeutet, dass CISA Belege dafür hat, dass Angreifer die Lücke außerhalb eines Labors einsetzen. Zivile Bundesbehörden müssen KEV-Einträge gemäß verbindlichen bundesweiten Vorgaben beheben.

Die betroffenen Produkte befinden sich an einem besonders sensiblen Punkt in Unternehmensnetzwerken. Ivanti Connect Secure ist ein Remote-Access-Gateway, das Nutzer mit internen Anwendungen und Cloud-Ressourcen verbindet. Es muss Internetverkehr annehmen und gleichzeitig vertrauenswürdige Verbindungen zu internen Identitätssystemen aufrechterhalten.

Diese Positionierung macht eine erfolgreiche Umgehung der Authentifizierung besonders folgenreich. Der Angreifer startet nicht von einem gewöhnlichen Mitarbeiterarbeitsplatz aus. Er beginnt an einem Gerät, das den Zugriff zwischen Internet und geschützten Diensten vermitteln soll.

CVE-2026-104935 hat einen CVSS-Score von 8,6. Die Schwachstelle wird als Authentifizierungsumgehung durch Spoofing eingestuft, was bedeutet, dass die Appliance Informationen, die zur Weiterleitung einer Anfrage verwendet werden, fälschlich vertraut. Die Ausnutzung erfordert geringe Komplexität, kein bestehendes Konto und keine Interaktion eines Opfers.

Ivanti zufolge sind folgende Releases betroffen:

• Version 25.1.1.1 und frühere Versionen innerhalb dieser Code-Linie

• Version 25.1.2.2 und frühere Versionen innerhalb dieser Code-Linie

• Version 22.8R2.4 und frühere Versionen innerhalb dieser Code-Linie

Zu den verfügbaren korrigierten Releases zählen 25.1.1.2, 25.1.3.0, 25.1.3.1 und 22.8R2.5. Administratoren müssen das Update der eingesetzten Produktlinie zuordnen und die aktuellen Hinweise im Security Advisory bestätigen.

Ivanti zufolge sind die Versionen 22.7.x und früher nicht von dieser konkreten Schwachstelle betroffen. Diese Aussage sollte nicht als allgemeine Zusicherung zu Support oder Sicherheit älterer Software verstanden werden. Unternehmen müssen den Lifecycle-Status und weitere Schwachstellen ihrer installierten Version separat prüfen.

Das Unternehmen erklärte, ihm seien bei der Offenlegung begrenzte Ausnutzungen bekannt gewesen. „Begrenzt“ beschreibt die Ivanti bekannten Fälle, nicht die Gesamtzahl kompromittierter Appliances. Raffinierte Akteure minimieren häufig Spuren, während vielen Organisationen eine vollständige Telemetrie von Netzwerk-Appliances fehlt.

Die Internet-Exponierung erhöht die Dringlichkeit. Shadowserver verfolgte nach der Offenlegung mehr als 5.500 offenbar online erreichbare Connect Secure-Instanzen. Diese Zahl kann Honeypots, doppelte Beobachtungen und Systeme umfassen, die bereits aktualisiert wurden.

Die Zahl verdeutlicht dennoch die erreichbare Angriffsfläche. Sobald sich technisches Wissen verbreitet, können Angreifer nach verwundbaren Gateways scannen, weitaus schneller als viele Unternehmen Wartungsarbeiten planen können. Eine exponierte Appliance ist daher sowohl durch den ursprünglichen Akteur als auch durch spätere Nachahmer gefährdet.

Deshalb verwendete CISA das Wort „sofort“. Normale monatliche Patch-Zyklen setzen voraus, dass Verteidiger Zeit haben, ein Update zu testen, zu planen und auszurollen. Bestätigte Zero-Day-Ausnutzung beseitigt diese Annahme.

Doch ein Update ist nur die erste Entscheidung. Die beobachtete Kampagne begann vor der öffentlichen Offenlegung und zielte auf eine Appliance mit der damals neuesten verfügbaren Version. Jede betroffene Organisation muss daher fragen, wann die Exponierung begann, nicht nur, wann ihr Patch installiert wurde.

Die Angreifer erlangten Root-Zugriff ohne Anmeldung

Der Exploit funktionierte, weil drei Schwachstellen eine Kette bildeten und eine öffentliche Login-Anfrage in die Ausführung von Befehlen mit Root-Rechten verwandelten.

Volexity entdeckte die Aktivität während einer Untersuchung, die am 5. Oktober begann. Die Forscher führten verdächtiges Verhalten auf eine Ivanti Connect Secure-Appliance mit Version 22.8R2.4, Build 19097, zurück. Dieses Release war zu diesem Zeitpunkt vollständig gepatcht.

Das Unternehmen stellte eine Ausnutzung seit dem 3. Oktober fest. Ein anderer Anbieter von Threat Intelligence beobachtete Berichten zufolge bereits seit dem 1. Oktober verwandte Anzeichen. Die öffentliche Offenlegung und Korrekturen folgten am 13. Oktober und ließen damit einen erheblichen Zeitraum unbekannter Exponierung.

Volexity verfolgt den nicht identifizierten Akteur unter der Bezeichnung UTA0576. Dieses Label kennzeichnet einen Aktivitätscluster, nicht eine bestätigte Organisation oder einen staatlichen Sponsor. Das Unternehmen bewertete mit geringer Sicherheit, dass die beobachtete Operation eher kriminell als spionagegetrieben motiviert war.

Der erste Schritt missbrauchte das Request-Routing rund um welcome.cgi, eine öffentliche Komponente, die die Anmeldeseite der Appliance bereitstellt. Angreifer übermittelten im Header X-DSCGI-PATH einen anderen Pfad. Die Appliance prüfte die öffentliche URL zur Autorisierung, verwendete jedoch den Header zur Auswahl des Ziels.

Diese Diskrepanz leitete eine nicht authentifizierte Anfrage an wu.cgi weiter, einen geschützten Upload-Handler. Das Ergebnis war eine Umgehung der Authentifizierung. Eine Komponente, die hinter Login-Kontrollen liegen sollte, wurde über eine öffentliche Anfrage erreichbar.

Der zweite Schritt nutzte eine kurze Race Condition bei der Dateiverarbeitung aus. Eine Race Condition tritt auf, wenn die Sicherheit davon abhängt, welche von zwei Operationen zuerst abgeschlossen wird. Hier schrieb der Upload-Handler eine bereitgestellte Datei, bevor er prüfte, ob es sich um ein gültiges ZIP-Archiv handelte.

Der Angreifer lud ein Perl-Skript mit der Erweiterung .zip hoch. Der Handler lehnte die ungültige Datei schließlich ab und löschte sie. Die Datei war jedoch vor dem Löschen kurzzeitig auf dem Datenträger vorhanden.

UTA0576 schickte parallele Anfragen, die versuchten, die temporäre Datei innerhalb dieses Zeitfensters auszuführen. Das Wiederholen dieser Anfragen erhöhte die Wahrscheinlichkeit, dass eine vor der Bereinigung eintraf. Erfolgreiches Timing führte zur Codeausführung unter dem eingeschränkten Konto cgi-server.

Ivanti fasste die Umgehung der Authentifizierung und die Remote-Code-Execution-Schritte unter CVE-2026-104935 zusammen. Die Releases vom 13. Oktober patchen diese Teile der Kette. Der dritte Schritt, der die Berechtigungen auf Root anhob, wird separat behandelt.

Zur Privilegieneskalation manipulierte der Akteur, wie ein privilegierter Hintergrunddienst Konfigurationsdaten vertraute. Der Exploit änderte eine Ivanti-Bibliothek im Prozessspeicher. Anschließend leitete er eine legitime Wartungsaufgabe auf ein bösartiges Perl-Skript um.

Der privilegierte Dienst führte dieses Skript als Root aus. Root-Zugriff verschafft einem Akteur die praktisch höchste Kontrolle über die zugrunde liegende Appliance. Der Exploit prüfte seinen Erfolg, indem er testete, ob er /etc/shadow lesen konnte, das geschützte Passwortinformationen auf Linux-Systemen speichert.

Der Akteur stellte danach die veränderte Konfiguration und Speicherinstruktion wieder her. Außerdem entfernte er ausgewählte Einträge aus Ivanti-Debug-Logs und Linux-Audit-Logs. Diese Maßnahmen reduzierten die nach jedem Befehl zurückbleibenden Beweise.

Die vollständige technische Rekonstruktion zeigt, dass der Angriff nicht aus einer einzigen Anfrage mit einer permanenten Payload bestand. Der Akteur führte die Exploit-Kette jedes Mal erneut aus, wenn ein weiterer Befehl benötigt wurde.

Diese Methode ist umständlich, bietet dem Angreifer aber einen defensiven Vorteil. Die Ermittler fanden auf der kompromittierten Appliance weder eine Backdoor der ersten Stufe noch eine herkömmliche Web Shell. Befehle und ihre Ausgabe wurden über die HTTPS-Anfragen des Exploits übertragen.

Einige Payload-Stufen existierten nur im Speicher. Eine Stufe entpackte ein komprimiertes, Base64-codiertes Python-Skript und führte es aus, ohne das Rohskript auf dem Datenträger zu hinterlassen. Die reine Speicherausführung begrenzt, was gewöhnliche dateibasierte Scans später wiederherstellen können.

Volexity zufolge umging die Kette auch Ivantis Integrity Checker Tool. Dieses Tool sucht nach unerwarteten Dateiänderungen, doch der Angriff veränderte vorübergehend Speicher- und Konfigurationsdaten. Der Exploit stellte diese Änderungen nach dem Erlangen von Root-Zugriff wieder her.

Diese Unterscheidung ist für jede betroffene Organisation wichtig. Ein Integritätscheck ohne unerwartete Dateimodifikationen beweist nicht, dass nie eine Ausnutzung stattgefunden hat. Er beantwortet nur die engere Frage, für deren Prüfung das Tool entwickelt wurde.

Der Diebstahl von Zugangsdaten machte das VPN zum Ausgangspunkt

UTA0576 nutzte das kompromittierte Gateway, um auf Identitätsdaten zuzugreifen, und verwandelte eine Appliance-Schwachstelle damit in ein umfassenderes Problem des Unternehmenszugriffs.

Die Aktivitäten des Akteurs nach der Ausnutzung konzentrierten sich auf Zugangsdaten, Verzeichnisinformationen, Netzwerkerkundung und das Abziehen von Daten. Diese Maßnahmen deuten auf Vorbereitungen für Bewegungen über die VPN-Appliance hinaus hin. Volexity zufolge wurde die Kampagne unterbrochen, bevor das endgültige Ziel des Angreifers klar wurde.

Active Directory war ein primäres Ziel. Active Directory ist Microsofts Verzeichnisdienst zur Verwaltung von Unternehmensidentitäten, Computern, Berechtigungen und Authentifizierung. Eine VPN-Appliance ist häufig über ein Dienstkonto damit verbunden, damit Remote-Nutzer verifiziert werden können.

UTA0576 nutzte den Zugriff der Appliance, um einen internen Domain Controller abzufragen. Ermittler stellten ein benutzerdefiniertes LDAP-Tool und zugehörige Python-Skripte wieder her. LDAP ist ein Protokoll zum Suchen und Verwalten von Verzeichnisinformationen.

Der Akteur suchte nach mehreren wertvollen Datentypen:

• Zugangsdaten für Local Administrator Password Solution

• BitLocker-Wiederherstellungsinformationen

• Attributen mit gespeicherten Passwortwerten

• Metadaten zu Benutzerkonten und Pfaden von Anmeldeskripten

• Gültigen Benutzernamen aus Authentifizierungsdatensätzen

Local Administrator Password Solution, oder LAPS, verwaltet lokale Administratorpasswörter für Windows-Geräte. BitLocker-Wiederherstellungsinformationen können verschlüsselte Windows-Laufwerke entsperren. Der Diebstahl beider Arten von Daten kann den Zugriff noch lange nach dem Patchen des verwundbaren VPNs ausweiten.

Der Angreifer komprimierte und codierte Verzeichnisergebnisse, bevor er sie über den Exploit-Kanal übertrug. Volexity bewertete mit hoher Sicherheit, dass der Akteur Informationen exfiltrierte, die über die gezielten Active Directory-Abfragen verfügbar waren.

UTA0576 untersuchte zudem auf der Appliance gespeicherte Paketmitschnitte. Der Akteur führte einen Parser aus, der in aufgezeichnetem Netzwerkverkehr nach Zugangsdaten und Material zum Knacken von Passwörtern suchen sollte. Zu den Zielen gehörten Klartext-LDAP-Zugangsdaten, HTTP Basic Authentication-Zugangsdaten und NTLM-Challenge-Response-Hashes.

NTLM-Hashes können Offline-Passwortangriffe oder andere Techniken zum Missbrauch von Zugangsdaten unterstützen. Das Risiko hängt von der Konfiguration der Organisation, der Passwortqualität und den Authentifizierungskontrollen ab. Ihre Erfassung verursacht weiterhin Sanierungsaufwand, der über die Aktualisierung eines einzelnen Geräts hinausgeht.

Ermittler fanden ein umbenanntes Paketaufzeichnungsprogramm, das aus einem versteckten Verzeichnis ausgeführt wurde. Es filterte Datenverkehr im Zusammenhang mit Klartextprotokollen, darunter LDAP, HTTP, FTP und Telnet. Acht rotierende Aufzeichnungsdateien begrenzten den Speicherbedarf, während sie fortlaufend ältere Daten ersetzten.

Die Kampagne umfasste auch interne DNS-Abfragen und Hostname-Aufklärung. Der Angreifer nutzte ein Hilfsskript für Password-Spraying gegen Active-Directory-Konten. Beim Password-Spraying wird eine kleine Auswahl wahrscheinlicher Passwörter über mehrere Konten hinweg getestet, um wiederholte Fehlversuche bei einem einzelnen Benutzernamen zu vermeiden.

Diese Aktivitäten zeigen, warum ein Edge-Appliance zu einer wertvollen Position für Informationsgewinnung werden kann. Sie verarbeitet Authentifizierungsabläufe und sieht Netzwerkverkehr, den gewöhnliche Endgeräte möglicherweise nie empfangen. Ihre Kompromittierung bietet sowohl einen Einstiegspunkt als auch eine Plattform zur Beobachtung interner Beziehungen.

Der beobachtete Angreifer durchsuchte zudem VPN-Konfigurationsverzeichnisse und Authentifizierungsprotokolle. Diese Aufzeichnungen können Authentifizierungsmethoden, Benutzernamen, interne Domains und verbundene Dienste offenlegen. Selbst erfolglose Suchen können einem Angreifer helfen, die nächste Phase zu planen.

Darin liegt die zentrale Umkehrung der CISA-Warnung. Organisationen beschaffen ein Remote-Access-Gateway, um Identitätsgrenzen durchzusetzen. In diesem Vorfall wurde das Gateway zu einem Weg, die Authentifizierung zu umgehen, und anschließend zu einer Quelle zusätzlicher Authentifizierungsmaterialien.

Das Risiko beschränkt sich nicht auf die lokalen Konten des Appliances. Administratoren müssen jedes Geheimnis berücksichtigen, das das Gerät gespeichert, übertragen, erfasst oder über ein integriertes Dienstkonto erreichen konnte. Der relevante Umfang kann Verzeichniszugangsdaten, Wiederherstellungsschlüssel, Tokens und Benutzerpasswörter einschließen.

Die Rotation von Zugangsdaten muss sich an Beweisen und der Architektur orientieren. Das Zurücksetzen aller Konten ohne Plan kann den Betrieb stören und gleichzeitig weniger sichtbare Dienstzugangsdaten übersehen. Teams sollten die Integrationen des Appliances identifizieren und Geheimnisse mit privilegiertem oder wiederverwendbarem Zugriff priorisieren.

Organisationen sollten außerdem Aktivitäten überprüfen, die vom Gateway ausgehen. Ein erfolgreicher Exploit kann bösartige Verbindungen so erscheinen lassen, als kämen sie von einem vertrauenswürdigen Netzwerkgerät. Nachgelagerte Systeme behandeln solche Verbindungen möglicherweise anders als gewöhnlichen Internetverkehr.

Volexity fand Anzeichen für Vorbereitungen zur lateralen Bewegung, also für den Übergang vom ursprünglich kompromittierten Gerät zu anderen Systemen. Das Unternehmen behauptete nicht, dass jede beobachtete Technik erfolgreich war. Es ermittelte auch nicht das letztliche Ziel des Angreifers.

Diese Unsicherheit sollte die Schlussfolgerungen eingrenzen, nicht die Eindämmung verzögern. Verteidiger verfügen über verifizierte Belege für den Diebstahl von Zugangsdaten und die Exfiltration von Daten aus mindestens einer untersuchten Umgebung. Sie sollten nicht davon ausgehen, dass ein aktualisiertes Appliance alle Folgen eines früheren Zugriffs beendet.

Patchen schließt den Einstiegspunkt, nicht die Untersuchung

Der zentrale Konflikt besteht nun zwischen Patchen und Beweisführung: Die Installation korrigierter Software ist notwendig, kann aber nicht feststellen, ob eine frühere Ausnutzung erfolgreich war.

Ivanti rät Kunden, sofort ein Upgrade durchzuführen und sein Integrity Checker Tool regelmäßig auszuführen. Diese Schritte verringern die Angriffsfläche und können bestimmte Formen von Manipulation erkennen. Sie decken jedoch nicht jede in diesem Vorfall dokumentierte Technik ab.

Volexity stellte fest, dass der Angreifer ausgewählte Protokolleinträge löschte und temporäre Änderungen rückgängig machte. Nach ihrer Nutzung entfernte der Angreifer zudem Skripte und Ausführungsergebnisse. Mehrere wichtige Komponenten liefen ausschließlich im Speicher.

Dieses anti-forensische Verhalten verändert den Wert eines unauffälligen Scans. Ein erwartetes Ergebnis kann bedeuten, dass das Appliance sauber ist. Es kann aber auch bedeuten, dass der Angreifer die Artefakte vermieden hat, die das gewählte Tool misst.

Die Analyse zur Reaktion von Rapid7 empfiehlt daher, nach Anwendung des Updates nach Kompromittierungsindikatoren zu suchen. Organisationen, die verdächtige Aktivitäten erkennen, sollten die Wiederherstellungsanleitung von Ivanti befolgen und nützliche Beweise sichern.

Netzwerktelemetrie kann Hinweise liefern, wenn Appliance-Protokolle nicht ausreichen. Volexity empfiehlt, nach ungewöhnlich hohen Anfragevolumina für den öffentlichen Pfad welcome.cgi zu suchen. Verteidiger können außerdem Abweichungen zwischen der angeforderten URL und dem Header X-DSCGI-PATH untersuchen.

Diese Indikatoren sind wertvoll, aber nicht vollständig. Angreifer können Pfade, Zeitabläufe, Infrastruktur und Post-Exploitation-Befehle anpassen. Das Fehlen eines veröffentlichten Musters sollte niemals als universeller Entlastungstest gelten.

Die Speicherakquise kann flüchtige Artefakte offenlegen, die Festplattenprüfungen übersehen. Das Erfassen von Speicher eines produktiven Gateways erfordert jedoch geeignete Verfahren und Fachkenntnisse. Ein unbedachter Neustart oder Neuaufbau kann Beweise zerstören, die zum Verständnis des Vorfalls benötigt werden.

Daraus entsteht ein operativer Zielkonflikt. Teams möchten das verwundbare Gerät rasch außer Betrieb nehmen. Ermittler möchten genügend Systemzustand erhalten, um festzustellen, was geschehen ist und welche Zugangsdaten ersetzt werden müssen.

Die richtige Reihenfolge hängt von Exposition, Geschäftsanforderungen, Redundanz und verfügbarer forensischer Unterstützung ab. Organisationen sollten Incident-Response-Teams frühzeitig einbeziehen, wenn sie Indikatoren oder unerklärliche Verbindungen vom Appliance feststellen. Sie sollten jede Eindämmungsmaßnahme und ihren Zeitpunkt dokumentieren.

Eine belastbare Reaktion trennt in der Regel vier Fragen:

1. Ist die installierte Version verwundbar?

2. War das Appliance während des Ausnutzungszeitraums erreichbar?

3. Gibt es Belege für einen versuchten oder erfolgreichen Exploit?

4. Welche Systeme und Zugangsdaten waren nach der Kompromittierung zugänglich?

Patchen beantwortet nur die erste Frage. Expositionsaufzeichnungen, Netzwerkprotokolle, Speicherbelege, Identitätsprotokolle und nachgelagerte Telemetrie beantworten die anderen. Diese Fragen als austauschbar zu behandeln, schafft falsches Vertrauen.

Die ungelöste Schwachstelle zur Privilegieneskalation bringt eine weitere Komplikation hinzu. Ivanti patchte die Komponenten für Authentifizierungsumgehung und Remote-Code-Ausführung am 13. Oktober. Volexity erklärte, Ivanti plane eine spätere Veröffentlichung für die separate Schwachstelle zur Privilegieneskalation.

Das bedeutet nicht, dass die dokumentierte Angriffskette nach den Oktober-Fixes weiterhin nutzbar bleibt. Das Schließen ihres nicht authentifizierten Einstiegs und ihrer Ausführungsstufen sollte diesen konkreten Weg unterbrechen. Administratoren sollten dennoch die zusätzliche Veröffentlichung verfolgen und sie installieren, sobald Ivanti sie bereitstellt.

Organisationen müssen außerdem prüfen, ob Updates tatsächlich vollständig abgeschlossen wurden. Appliance-Cluster, Standby-Knoten, Disaster-Recovery-Systeme und vergessene Test-Gateways können nach Änderungen am Primärgerät weiterhin verwundbar sein. Asset-Aufzeichnungen sollten mit realen Versionsdaten abgeglichen werden.

Externe Erkennung kann helfen, nicht verwaltete Exposition aufzudecken. Das Expositions-Dashboard von Shadowserver bietet eine externe Sicht, doch kein externer Datensatz liefert ein perfektes Inventar. Interne Verantwortlichkeitsaufzeichnungen bleiben unverzichtbar.

Eine vollständige Reaktion muss Identitätskontrollen einschließen. Teams sollten Authentifizierungsmuster, die Nutzung von Dienstkonten, privilegierte Verzeichnisabfragen, Signale für Password-Spraying und ungewöhnliche Zugriffe auf Wiederherstellungsschlüssel untersuchen. Relevante Geheimnisse sollten rotiert werden, nachdem Teams ihre Abhängigkeiten verstanden haben.

Nachgelagerte Systeme verdienen eine gesonderte Überprüfung. Verbindungen vom VPN-Appliance könnten Vertrauen geerbt oder Kontrollen umgangen haben, die für gewöhnliche Clients gelten. Ermittler sollten ungewöhnlichen Datenverkehr identifizieren, der während des vermuteten Zeitraums vom Gateway ausging.

Die sicherste Schlussfolgerung ist zugleich die unbequemste: Für diesen Vorfall gibt es keinen einzelnen „Entwarnung“-Button. Korrigierte Software, unauffällige Integritätsergebnisse und das Fehlen veröffentlichter Indikatoren liefern jeweils Belege. Keines davon beweist für sich allein, dass ein Gerät niemals kompromittiert wurde.

Frühere Zero-Days von Ivanti erhöhen den Druck

CVE-2026-104935 folgt auf wiederholte Ausnutzung von Edge-Produkten, weshalb Kunden neben einem einzelnen Patch auch die Reife der Reaktion bewerten.

Ivanti Connect Secure war in den vergangenen Jahren mehreren schwerwiegenden, aktiv ausgenutzten Schwachstellen ausgesetzt. Anfang 2024 verketteten Angreifer CVE-2023-46805 mit CVE-2024-21887. Diese Kombination ermöglichte die Umgehung der Authentifizierung und Command Injection gegen internetexponierte Gateways.

CISA reagierte in dieser Episode entschieden. Bundesbehörden erhielten Anweisungen, Gegenmaßnahmen anzuwenden, Integritätsprüfungen durchzuführen und betroffene Geräte unter festgelegten Bedingungen letztlich vom Netz zu trennen. Spätere Analysen warnten, dass Angreifer trotz einiger Wiederherstellungsmaßnahmen Zugriff behalten könnten.

Im Januar 2025 legte Ivanti die aktive Ausnutzung von CVE-2025-0282 offen, einem stackbasierten Buffer Overflow, der Connect Secure betrifft. Später in diesem Jahr wurde eine weitere Connect-Secure-Schwachstelle, CVE-2025-22457, mit der Ausnutzung durch eine China-zugeordnete Spionagegruppe in Verbindung gebracht.

Der neue Vorfall beweist nicht, dass jedes Ivanti-Appliance kompromittiert oder einzigartig unsicher ist. Enterprise-Edge-Produkte mehrerer Anbieter ziehen intensive Forschung und anhaltendes Interesse von Angreifern an. Ihre Position macht einen erfolgreichen Exploit besonders wertvoll.

Volexity zog einen direkten Vergleich mit der jüngsten Ausnutzung von SonicWall Secure Mobile Access Appliances. In beiden Fällen untersuchten Angreifer mit Root-Zugriff Paketmitschnitte, um Zugangsdaten wiederherzustellen. Die Überschneidung deutet auf eine breitere Strategie gegen vertrauenswürdige Systeme am Netzwerkrand hin.

VPN-Gateways teilen mehrere Eigenschaften, die Angreifern entgegenkommen. Sie sind aus dem Internet erreichbar, arbeiten häufig kontinuierlich und sind direkt mit der Identitätsinfrastruktur verbunden. Außerdem laufen sie in spezialisierten Betriebsumgebungen, die viele Endpoint-Sicherheitsprodukte nicht normal überwachen können.

Eine Workstation kann Endpoint Detection, Anwendungskontrollen und detaillierte Prozesstelemetrie besitzen. Ein Sicherheits-Appliance stellt seinem Eigentümer häufig weniger Untersuchungswerkzeuge bereit. Angreifer können diese Transparenzlücke ausnutzen, während sie von einer hoch vertrauenswürdigen Netzwerkposition aus agieren.

Das wiederkehrende Muster setzt sowohl Anbieter als auch Kunden unter Druck. Anbieter müssen den Zeitraum zwischen der Entdeckung einer Teil-Schwachstelle und dem Schutz aller unterstützten Branches verkürzen. Kunden müssen ihre Abhängigkeit von Notfallmeldungen als primärem Erkennungsmechanismus reduzieren.

Ivanti erklärte, ein Teil von CVE-2026-104935 sei über sein Product-Security-Programm entdeckt worden. Diese Komponente wurde in der Juli-2026-Version 25.1.3.0 behoben. Die Ausnutzung erfolgte, während das Unternehmen den Fix auf andere unterstützte Versionen zurückportierte.

Dieser Zeitablauf verdient eine genaue Prüfung, stützt jedoch keine einfache Anschuldigung. Das Zurückportieren von Sicherheitsänderungen über Release-Branches hinweg kann Engineering- und Kompatibilitätstests erfordern. Öffentliche Details belegen nicht, wann Ivanti die vollständige Exploit-Kette oder ihre Nutzung in der Praxis verstand.

Das Ergebnis legte dennoch eine Patch-Lücke offen. Einige Kunden auf anderen unterstützten Branches blieben verwundbar, nachdem ein Branch bereits einen relevanten Fix enthielt. Angreifer agierten während dieses Zeitraums und kompromittierten eine Version, die für ihre Linie als aktuell galt.

Daraus ergibt sich eine praktische Beschaffungsfrage. Käufer sollten fragen, wie Anbieter Sicherheitsfixes über unterstützte Branches hinweg verteilen. Sie sollten außerdem fragen, ob Erkennungsleitlinien zusammen mit dem Fix bereitgestellt werden und wie Appliances forensische Beweise bewahren.

Kunden können die künftige Exposition reduzieren, ohne auf eine weitere Warnung zu warten. Sie können die direkte Erreichbarkeit aus dem Internet minimieren, administrative Schnittstellen beschränken und vom Gateway ausgehenden Datenverkehr überwachen. Außerdem können sie Protokolle zentralisieren, damit ein Angreifer nicht jeden lokal verfügbaren nützlichen Eintrag löschen kann.

Auch Segmentierung ist wichtig. Ein Remote-Access-Appliance sollte nicht uneingeschränkte Reichweite erhalten, nur weil es eine vertrauenswürdige Funktion erfüllt. Seine Dienstkonten sollten nur die erforderlichen Berechtigungen besitzen, während Klartext-Authentifizierungsprotokolle, wo möglich, entfernt werden sollten.

Diese Maßnahmen beseitigen das Zero-Day-Risiko nicht. Sie begrenzen den Nutzen, den Angreifer nach dem Ausfall eines Geräts erzielen können. Die wiederkehrende Lehre aus Vorfällen bei Ivanti, SonicWall, Citrix und anderen Edge-Systemen lautet, dass Perimeter-Appliances ebenfalls interne Eindämmungsmechanismen benötigen.

Der Druck auf Ivanti wird daher über die Bereitstellung von Updates hinausgehen. Kunden werden beobachten, wie schnell der noch ausstehende Fix für die Rechteausweitung erscheint. Außerdem werden sie bewerten, ob neue Releases die Beweissicherung verbessern und Manipulationen, die ausschließlich im Speicher stattfinden, widerstandsfähiger begegnen.

Drei Signale werden zeigen, ob die Reaktion funktioniert hat

Die nächste Phase hängt vom Wachstum der Ausnutzung, dem verbleibenden Ivanti-Fix und Hinweisen auf Kompromittierungen außerhalb der zunächst untersuchten Umgebungen ab.

Das erste Signal ist, ob Scans und Ausnutzungsversuche nach der öffentlichen Offenlegung zunehmen. Technische Details sind inzwischen verfügbar, auch wenn Volexity keinen einsatzfähigen Exploit-Code veröffentlicht hat. Andere Akteure können die Routing-Schwachstelle dennoch untersuchen, die Race Condition reproduzieren und eine eigene Implementierung entwickeln.

Ein starker Anstieg von Anfragen mit Bezug zu welcome.cgi oder verdächtigen X-DSCGI-PATH-Werten würde die Argumente für sofortige Eindämmungsmaßnahmen erhärten. Berichte von Incident-Response-Firmen werden zeigen, ob UTA0576 der wichtigste Akteur blieb oder zu einem von vielen wurde.

Das zweite Signal ist Ivantis zugesagter Fix für die separate Schwachstelle zur Rechteausweitung. Administratoren sollten das Security Advisory des Unternehmens, die Release Notes und Hinweise zu unterstützten Versionen verfolgen. Nach der Bereitstellung sollten sie jeden aktiven und jeden Standby-Knoten überprüfen.

Eine zeitnahe Veröffentlichung würde einen weiteren lokalen Eskalationsweg beseitigen, der in der Angriffskette dokumentiert wurde. Eine Verzögerung würde Kunden mit zusätzlicher Unsicherheit zurücklassen, selbst nachdem CVE-2026-104935 selbst gepatcht wurde.

Das dritte Signal ist die Entdeckung nachgelagerter Kompromittierungen. Neue Berichte über gestohlene Verzeichniszugangsdaten, unbefugten Zugriff auf BitLocker-Wiederherstellungsdaten oder laterale Bewegungen würden die bislang bekannten Auswirkungen des Vorfalls erweitern. Sie würden zudem bestätigen, dass eine ausschließlich auf die Appliance ausgerichtete Behebung zu eng gefasst war.

Organisationen sollten nicht auf solche Berichte warten, bevor sie ihre eigenen Umgebungen prüfen. Der beobachtete Akteur suchte unmittelbar nach dem Erlangen von Root-Zugriff nach Identitätsgeheimnissen. Dieses Verhalten definiert den Mindestumfang der Untersuchung für exponierte Systeme.

Verteidiger sollten Gateway-, Firewall-, Identitäts-, DNS- und Verzeichnisprotokolle für das gesamte Zeitfenster der Exponierung sichern. Sie sollten nach Verbindungen von der Appliance suchen, die nicht dem normalen Remote-Access-Verhalten entsprechen. Relevante Dienstkonten und wiederverwendbare Geheimnisse erfordern besondere Aufmerksamkeit.

Die Schwachstelle in Ivanti Connect Secure bietet zudem einen umfassenderen Test für Programme zum Schwachstellenmanagement. Die Geschwindigkeit der Inventarisierung ist ebenso wichtig wie die Patch-Geschwindigkeit. Eine Organisation kann kein Standby-Gateway, kein vergessenes Laborgerät und keine übernommene Appliance schützen, für die sich niemand verantwortlich fühlt.

Die Warnung der CISA sollte daher einen koordinierten Workflow auslösen. Security Operations, Netzwerktechnik, Identitätsteams und Incident Responder benötigen dieselbe Zeitleiste und dieselbe Asset-Liste. Jedes Team sieht einen anderen Teil des Angriffspfads.

Patches bleiben dringend, sind aber nur der erste Schritt. Die wichtigere Frage lautet, ob Ihre Organisation nachweisen kann, auf was die Appliance zugriff, bevor der Patch verfügbar war. Prüfen Sie das Advisory, bestätigen Sie jede eingesetzte Version, sichern Sie Beweise und untersuchen Sie jetzt von Gateways ausgehende Aktivitäten. Wenn das Gerät Zugriff auf wertvolle Identitätsdaten hatte: Behandeln Sie dies als routinemäßige Wartung oder als möglichen Sicherheitsvorfall?