Ivanti Connect Secure Schwachstelle: CVE-2025-22457 aktiv ausgenutzt

Kritischer Stack-Overflow mit CVSS 9.0 – was Krankenhäuser jetzt tun müssen

Eine kritische Sicherheitslücke in Ivanti Connect Secure wird seit Frühjahr 2025 aktiv ausgenutzt – auch in Deutschland sind noch über 180 Systeme mit veralteten Software-Versionen im Einsatz. Für Krankenhäuser und Gesundheitseinrichtungen, die Ivanti-Produkte für den Remote-Zugang einsetzen, besteht unmittelbarer Handlungsbedarf. Der folgende Artikel analysiert die technischen Details, erklärt die Implikationen für das Patch-Management und leitet konkrete Maßnahmen für ISB und IT-Leitung ab.

Was steckt hinter CVE-2025-22457?

Am 3. April 2025 veröffentlichte Ivanti ein Advisory zu einer Sicherheitslücke, die sämtliche Versionen von Ivanti Connect Secure, Policy Secure und ZTA Gateways bis einschließlich Version 22.7.R2.5 betrifft. Das BSI stufte die Ivanti Connect Secure Schwachstelle mit Kritikalitätsstufe 3 (von 4) ein – der CVSS-Score liegt bei 9.0 und damit im kritischen Bereich.

Technisch handelt es sich um einen Stack-basierten Pufferüberlauf (CWE-121). Die Schwachstelle erlaubt einem nicht authentifizierten Angreifer, beliebigen Code auf dem betroffenen System auszuführen – ohne dass ein gültiger Account oder eine vorherige Authentifizierung erforderlich wäre. Remote Code Execution (RCE) ohne Authentifizierung an einem VPN-Gateway ist aus Angreiferperspektive ein nahezu ideales Einfallstor: Das Gerät ist typischerweise direkt aus dem Internet erreichbar, und eine erfolgreiche Kompromittierung verschafft dem Angreifer Zugang zum internen Netzwerk.

Besonders brisant: Ein Patch existierte bereits seit dem 11. Februar 2025 – Ivanti hatte das Problem bis April intern als Softwarefehler (Bug) klassifiziert, nicht als Sicherheitslücke. Erst nach externer Analyse durch Mandiant und Ivanti erfolgte die Neubewertung als kritische Sicherheitsschwachstelle. Diese Verzögerung zwischen Patch-Verfügbarkeit und CVE-Veröffentlichung hatte direkte Konsequenzen: Viele Organisationen, die auf CVE-Veröffentlichungen als primären Trigger für das Patch-Management setzen, hatten das Update über zwei Monate nicht eingespielt.

Verwundbare Produktversionen im Überblick:

Produkt	Betroffene Versionen
Ivanti Connect Secure	≤ 22.7.R2.5 sowie End-of-Support-Versionen (Pulse Connect Secure 9.1.x)
Ivanti Policy Secure	≤ 22.7.R2.5
Ivanti ZTA Gateways	≤ 22.7.R2.5

Die gesicherte Version für Connect Secure ist 22.7.R2.6. Für Pulse Connect Secure 9.1.x existiert kein Patch – diese Produktlinie hat End of Support (EoS) erreicht.

Aktive Ausnutzung: Was BSI und Mandiant berichten

Das BSI bestätigte in seiner Sicherheitsmitteilung vom 9. April 2025, dass CVE-2025-22457 zum Zeitpunkt der Veröffentlichung bereits aktiv ausgenutzt wurde – sowohl auf ungepatchten Systemen im Support als auch auf End-of-Support-Geräten. Mandiant, das gemeinsam mit Ivanti die Analyse durchführte, berichtete von gezielten Angriffen, bei denen nach erfolgreicher Ausnutzung TRAILBLAZE und BRUSHFIRE als In-Memory-Dropper sowie das SPAWN-Malware-Ökosystem eingesetzt wurden. Diese Werkzeuge sind auf Persistenz ausgelegt und hinterlassen minimale forensische Spuren.

Für Deutschland ist die Lage konkret: Über 180 Systeme mit veralteten Software-Versionen waren laut BSI noch am 8. April 2025 aktiv im Einsatz – ein erheblicher Teil davon auf End-of-Support-Versionen ohne Patching-Option.

Ivanti Connect Secure ist ein weit verbreitetes SSL-VPN-Produkt, das häufig als primärer Remote-Access-Kanal eingesetzt wird – auch in Krankenhäusern und bei Dienstleistern im Gesundheitswesen. Die Kompromittierung eines solchen Gateways kann Angreifern direkten Zugang zu klinischen Systemen, KIS, RIS/PACS oder administrativen Netzen verschaffen und ist ein klassischer erster Schritt bei Ransomware-Angriffen auf Gesundheitseinrichtungen.

Warum End-of-Support-Systeme ein strukturelles Risiko sind

Der Fall CVE-2025-22457 illustriert ein bekanntes, aber in der Praxis oft unterschätztes Problem: End-of-Support-Software in produktiven Umgebungen. Pulse Connect Secure 9.1.x erhält keine Sicherheitsupdates mehr – wer diese Version betreibt, hat schlicht keine Möglichkeit, die Schwachstelle zu schließen, außer durch Produktwechsel oder -upgrade.

Im Krankenhaus begegnet man EoS-Systemen häufig in zwei Konstellationen: erstens bei Netzwerkkomponenten und Security Appliances, die im Beschaffungsrhythmus als "läuft doch noch" mitlaufen, und zweitens als Konsequenz von Projektverzögerungen bei Migrationen. Beide Szenarien sind aus Compliance-Sicht problematisch.

Regulatorischer Kontext: Nach §391 SGB V sind Krankenhäuser verpflichtet, angemessene technische und organisatorische Maßnahmen zur IT-Sicherheit umzusetzen. Der B3S Krankenhaus (Branchenspezifischer Sicherheitsstandard) fordert im Rahmen des Asset- und Patch-Managements explizit die Behandlung von EoS-Software als erhöhtes Risiko mit dokumentiertem Risikomanagement-Prozess. Der BSI IT-Grundschutz (insbesondere SYS.1.1 und NET.3.2) verlangt ebenfalls, dass nicht mehr unterstützte Betriebssysteme und Firmware entweder abgelöst oder durch kompensatorische Maßnahmen gesichert werden.

Seit Inkrafttreten des NIS2UmsuCG in Deutschland gelten für Einrichtungen im Gesundheitswesen, die unter die NIS2-Richtlinie fallen, zusätzlich verschärfte Anforderungen an das Risikomanagement nach §30 BSIG. Der Betrieb bekannter, ungepatchter kritischer Schwachstellen in exponierten Systemen ist mit diesen Anforderungen kaum vereinbar und kann im Meldefall nach §32 BSIG zu aufsichtsbehördlicher Prüfung führen.

Sofortmaßnahmen und Patch-Management-Empfehlungen

Priorität 1: Sofortiger Handlungsbedarf

Wenn Ivanti Connect Secure, Policy Secure oder ZTA Gateways in Ihrer Umgebung betrieben werden, sind folgende Schritte unverzüglich einzuleiten:

1. Asset-Inventar prüfen Identifizieren Sie alle Ivanti-Instanzen in Ihrer Umgebung inklusive Versionsstände. Berücksichtigen Sie dabei auch von Dienstleistern betriebene Systeme, über die Remote-Zugang auf Ihre Infrastruktur gewährt wird – Supply-Chain-Angriffsvektoren über externe Dienstleister sind im Gesundheitswesen keine theoretische Bedrohung.

2. Patch einspielen: Connect Secure auf 22.7.R2.6 Für unterstützte Versionen ist der Patch seit dem 11. Februar 2025 verfügbar. Spielen Sie ihn sofort ein, falls noch nicht geschehen. Prüfen Sie anschließend die Integrität des Systems (siehe Schritt 4).

3. End-of-Support-Systeme isolieren oder abschalten Pulse Connect Secure 9.1.x kann nicht gepatcht werden. Bis zur Migration oder Ablösung müssen diese Systeme zwingend durch kompensatorische Maßnahmen geschützt werden: - Netzwerkseitige Isolation oder Abschaltung des externen Zugangs - Restriktive IP-Whitelisting auf vorgelagerten Firewalls - Erhöhtes Monitoring auf Anomalien - Risikoakzeptanz schriftlich dokumentieren und durch Geschäftsführung/Krankenhausleitung formell bestätigen lassen

4. Systeme auf Kompromittierung prüfen Da die Schwachstelle aktiv ausgenutzt wird und die eingesetzten Malware-Komponenten auf Persistenz und Stealth ausgelegt sind, reicht das Einspielen des Patches allein nicht aus. Prüfen Sie: - Ivantis Integritätsprüfungs-Tool (Ivanti Integrity Checker Tool – ICT) ausführen - Log-Analyse auf ungewöhnliche Authentifizierungen, Tunnel-Etablierung, laterale Bewegungen - Netzwerk-Traffic-Analyse auf C2-Kommunikation - Bei begründetem Verdacht: Forensische Untersuchung durch spezialisiertes Team, kein regulärer Betrieb des Systems

5. Incident-Response-Prozess aktivieren (bei Verdacht) Wenn Anzeichen für eine Kompromittierung vorliegen, gilt: Isolierung des Systems vor Patch, Sicherung von Logs und forensischen Artefakten, Einleitung des Incident-Response-Prozesses gemäß Ihrer ISMS-Dokumentation. Für KRITIS-Einrichtungen und unter NIS2 meldepflichtige Einrichtungen gilt: Meldepflicht nach §32 BSIG bei erheblichen Sicherheitsvorfällen gegenüber dem BSI – Fristen und Schwellenwerte beachten.

Strukturelle Lehren für das Patch-Management im Krankenhaus

CVE-2025-22457 ist kein Einzelfall – er reiht sich ein in eine Serie kritischer Ivanti-Schwachstellen (CVE-2023-46805, CVE-2024-21887, CVE-2025-0282), die in den vergangenen Jahren aktiv ausgenutzt wurden. Das Muster ist bekannt: VPN-Gateways als exponierte Angriffsfläche, verzögerte Patch-Kommunikation durch Hersteller, EoS-Systeme im produktiven Einsatz.

Folgende strukturelle Maßnahmen sollten in Ihrem ISMS verankert sein:

Risikoorientiertes Patch-Management: Nicht alle Patches sind gleich. Ein Bewertungsrahmen, der Exponierung (ist das System direkt aus dem Internet erreichbar?), Kritikalität (CVSS-Score, KEV-Status) und Geschäftsrelevanz kombiniert, ermöglicht priorisiertes Handeln. Exponierten Systemen wie VPN-Gateways sollte generell eine höhere Patch-Priorität zukommen als internen Systemen.

Monitoring von Herstellerkommunikation jenseits von CVEs: Der Fall Ivanti zeigt, dass CVE-Veröffentlichungen nicht der einzige Trigger sein dürfen. Herstelleradvisories, Bug-Fix-Releases und Hinweise von Sicherheitsforschern müssen in den Monitoring-Prozess integriert werden. Das BSI CERT-Bund bietet über den Warn- und Informationsdienst (WID) entsprechende Benachrichtigungen an.

EoS-Tracking als Pflichtbestandteil des Asset-Managements: Jedes System im Asset-Inventar sollte mit End-of-Support-Datum gepflegt sein. Systeme, die innerhalb von 12 Monaten EoS erreichen, benötigen einen dokumentierten Migrationsplan. Systeme, die bereits EoS sind, müssen entweder abgelöst oder als Risikoakzeptanz mit kompensatorischen Maßnahmen formal behandelt werden.

Netzwerksegmentierung als Schutzmaßnahme: VPN-Gateways sollten in einer DMZ oder einem dedizierten Segment betrieben werden, das eine kontrollierte Kommunikation in interne Netze erzwingt. Eine erfolgreiche Kompromittierung des Gateways darf nicht unmittelbaren Zugang zu klinischen Systemen ermöglichen.

Regelmäßige Überprüfung von Remote-Zugangskomponenten: Krankenhäuser sollten mindestens quartalsweise eine Überprüfung aller extern erreichbaren Systeme inklusive Versionsstände durchführen – idealerweise unterstützt durch automatisiertes Vulnerability-Scanning (z. B. via SIEM-Integration oder dediziertes VM-Tool).

Eine strukturierte Selbstbewertung Ihrer aktuellen Sicherheitslage können Sie mit dem ISMShield Assessment durchführen – es deckt unter anderem Patch-Management und Expositionsrisiken ab.

Checkliste: Ivanti CVE-2025-22457 – Sofortmaßnahmen

[ ] Ivanti Connect Secure, Policy Secure, ZTA Gateways im Asset-Inventar identifiziert
[ ] Versionsstände aller Instanzen geprüft (inkl. von Dienstleistern betriebene Systeme)
[ ] Patch auf Version 22.7.R2.6 eingespielt (Connect Secure)
[ ] Ivanti Integrity Checker Tool (ICT) ausgeführt, Ergebnis dokumentiert
[ ] End-of-Support-Systeme (Pulse Connect Secure 9.1.x) identifiziert und isoliert/kompensiert
[ ] Risikoakzeptanz für nicht patchbare EoS-Systeme formal dokumentiert und genehmigt
[ ] Log-Analyse auf Kompromittierungshinweise durchgeführt
[ ] Incident-Response-Prozess bei Verdachtsfällen aktiviert
[ ] Meldepflicht nach §32 BSIG geprüft (bei erheblichen Vorfällen)
[ ] EoS-Tracking und Migrationsplanung im ISMS verankert

Quellen und we

Kostenlose NIS2-Bestandsaufnahme starten →