Ivanti EPMM Sicherheitslücke: Kritische Zero-Days aktiv ausgenutzt
Mobilgeräte-Management-Lösungen gehören zur unsichtbaren Infrastruktur vieler Krankenhäuser – und genau deshalb sind sie ein attraktives Ziel für Angreifer. Mit den CVE-2026-1281 und CVE-2026-1340 stehen zwei kritische Schwachstellen in Ivanti Endpoint Manager Mobile (EPMM) im Fokus, die seit mindestens Sommer 2025 aktiv ausgenutzt werden. Das BSI hat am 13. Februar 2026 seine Sicherheitsmitteilung auf Version 1.3 aktualisiert und bestätigt: Auch deutsche Organisationen sind bereits Ziel dieser Angriffe geworden. Für IT-Verantwortliche in Kliniken besteht unmittelbarer Handlungsbedarf.
Was ist passiert: Chronologie einer aktiven Bedrohungslage
Am 29. Januar 2026 veröffentlichte Ivanti ein Advisory zu zwei kritischen Schwachstellen in EPMM, dem früheren MobileIron Core. Bereits zum Zeitpunkt der Veröffentlichung hatte Ivanti aktive Ausnutzung von CVE-2026-1281 bei einer begrenzten Anzahl von Kunden bestätigt.
Die Eskalation erfolgte rasant: Am 30. Januar veröffentlichte das IT-Sicherheitsunternehmen watchTowr Labs einen Blogbeitrag mit technischen Details sowie einen funktionsfähigen Proof-of-Concept (PoC). Innerhalb von Stunden beobachteten das BSI und internationale Partner eine deutliche Zunahme der Angriffsversuche durch weitere Cyberakteure. Damit war aus einer begrenzten Bedrohung ein breit gestreutes Angriffsszenario geworden.
Besonders beunruhigend ist der Zeithorizont: Dem BSI liegen Hinweise vor, dass eine Ausnutzung der Ivanti EPMM Sicherheitslücke möglicherweise bereits seit Sommer 2025 stattgefunden hat – also Monate vor der offiziellen Entdeckung und Veröffentlichung. Für betroffene Organisationen bedeutet das: Wer EPMM betreibt und noch keine forensische Analyse durchgeführt hat, kann einen länger zurückliegenden Einbruch bislang nicht ausschließen.
Das BSI stuft die Bedrohung mit Kritikalität 3 ein und hat bestätigt, dass auch deutsche Organisationen Ziel der Angreifer wurden.
Technische Analyse: Was die Schwachstellen ermöglichen
CVE-2026-1281 und CVE-2026-1340 im Überblick
Beide Schwachstellen betreffen Ivanti EPMM (Endpoint Manager Mobile) und wurden nach CVSS 3.1 mit einem Score von 9.8 ("kritisch") bewertet. Das Angriffsszenario ist aus Angreifer-Perspektive nahezu ideal:
- Kein Authentifizierungserfordernis: Ein entfernter, nicht-authentifizierter Angreifer kann die Schwachstellen ausnutzen – eine gültige Kennung oder ein Session-Token ist nicht notwendig.
- Remote Code Execution (RCE): Die Schwachstellen ermöglichen die direkte Ausführung von Code auf der EPMM-Appliance.
- Datenzugriff: EPMM-Appliances speichern per Design sensible Informationen über alle verwalteten Geräte – Gerätekonfigurationen, Zertifikate, Netzwerkparameter, potenziell auch Zugangsdaten für verwaltete Dienste.
- Lateral Movement: Über die kompromittierte EPMM-Instanz können Angreifer sich im verbundenen Netzwerk weiter ausbreiten.
Beobachtete Angriffsmuster
Forensische Analysen der bislang dokumentierten Vorfälle zeigen ein heterogenes Bild: Die verwendeten Payloads und Indicators of Compromise (IoCs) variieren zwischen den Angriffen erheblich – ein klares Zeichen dafür, dass mehrere unabhängige Bedrohungsakteure die Schwachstelle parallel ausnutzen.
Ein gemeinsames Muster wurde dennoch mehrfach beobachtet: Die Kompromittierung von EPMM-Appliances durch .jsp-Dateien, die als In-Memory Class Loader fungieren. Diese Technik ermöglicht es Angreifern, Code im Arbeitsspeicher auszuführen, ohne persistente Dateispuren auf dem Dateisystem zu hinterlassen – was die forensische Erkennung erheblich erschwert und erklärt, warum möglicherweise monatelange Kompromittierungen unentdeckt blieben.
Relevanz für Krankenhaus-IT
In Kliniken verwaltet EPMM typischerweise mobile Endgeräte wie Tablets und Smartphones im klinischen Betrieb – Visitengeräte, Kommunikations-Endgeräte für Pflegepersonal, oder Geräte mit Zugriff auf Krankenhausinformationssysteme (KIS). Eine Kompromittierung der MDM-Infrastruktur ist damit ein Einstiegsvektor mit unmittelbarer Patientenrelevanz: Angreifer können über verwaltete Geräte in klinische Netzwerke pivotieren und von dort Ransomware ausrollen oder auf Patientendaten zugreifen.
Sofortmaßnahmen: Was IT-Verantwortliche jetzt tun müssen
1. Patch einspielen – unverzüglich
Ivanti hat Patches für die betroffenen EPMM-Versionen bereitgestellt. Die Installation sollte ohne Verzögerung erfolgen – ein Wartungsfenster der nächsten regulären Runde ist hier nicht angemessen. Prüfen Sie die aktuellen Versionsempfehlungen im Ivanti Security Advisory und stellen Sie sicher, dass alle EPMM-Instanzen (inklusive etwaiger Test- oder Backup-Systeme) aktualisiert werden.
2. Erkennungsskript ausführen – auch nach Patchen
Ivanti hat in Zusammenarbeit mit dem niederländischen NCSC (NCSC-NL) ein Exploitation Detection RPM Package entwickelt, das auf Appliances nach bekannten Kompromittierungsindikatoren sucht. Am 12. Februar 2026 wurde das Skript mit neuen IoCs aktualisiert (Version 2). Wichtig: Das Skript sollte auch dann ausgeführt werden, wenn der Patch bereits eingespielt wurde – denn eine vor dem Patchen erfolgte Kompromittierung wird durch das Update nicht rückgängig gemacht.
Beziehen Sie das Skript ausschließlich über die offiziellen Ivanti-Kanäle und überprüfen Sie die Integrität vor der Ausführung.
3. Netzwerkzugriff auf EPMM restriktieren
Sofern noch nicht geschehen: Begrenzen Sie den Netzwerkzugriff auf die EPMM-Verwaltungsoberfläche auf autorisierte Administrationsnetzwerke. Eine öffentlich erreichbare MDM-Konsole entspricht nicht dem Prinzip der minimalen Angriffsfläche und widerspricht den Anforderungen aus BSI IT-Grundschutz (insbesondere Baustein NET.1.1 Netzarchitektur und -design sowie SYS.1.1 Allgemeiner Server). Prüfen Sie, ob die Appliance über das Internet erreichbar ist – und schränken Sie dies gegebenenfalls sofort ein.
4. Logs sichern und forensisch auswerten
Angesichts der Hinweise auf eine möglicherweise seit Sommer 2025 laufende Ausnutzung sollten verfügbare Logs der EPMM-Appliance umgehend gesichert und auf Auffälligkeiten untersucht werden. Achten Sie insbesondere auf:
- Unbekannte
.jsp-Dateien in Web-Verzeichnissen - Ungewöhnliche Prozesse oder Netzwerkverbindungen der Appliance
- Zugriffe auf die EPMM-API von unbekannten IP-Adressen
- Unerwartete Änderungen an Geräteprofilen oder Zertifikaten
Wenn Ihr SIEM EPMM-Logs nicht bereits ingestiert, ist jetzt der richtige Zeitpunkt, das zu ändern.
5. Incident-Response-Prozess anstoßen bei Verdacht
Falls das Erkennungsskript Indikatoren einer Kompromittierung liefert oder die Log-Analyse Auffälligkeiten zeigt, gilt: Behandeln Sie den Vorfall als bestätigten Sicherheitsvorfall. Aktivieren Sie Ihren Incident-Response-Plan, isolieren Sie die betroffene Appliance und ziehen Sie externen forensischen Sachverstand hinzu.
Regulatorische Pflichten: Meldung und Dokumentation
Meldepflichten nach BSIG und NIS2UmsuCG
Für Krankenhäuser, die als KRITIS-Betreiber eingestuft sind oder unter das NIS2UmsuCG fallen, bestehen bei erheblichen Sicherheitsvorfällen Meldepflichten gegenüber dem BSI. Die relevanten Normen sind:
- § 32 BSIG (Meldepflichten für KRITIS-Betreiber und NIS2-Einrichtungen): Erhebliche Sicherheitsvorfälle sind dem BSI unverzüglich zu melden – innerhalb von 24 Stunden für die Erstmeldung, innerhalb von 72 Stunden für die Folgemeldung.
- Eine Kompromittierung der EPMM-Infrastruktur mit nachgewiesenem oder wahrscheinlichem Zugriff auf Patientendaten löst zusätzlich DSGVO-Meldepflichten aus (Art. 33 DSGVO: Meldung an die zuständige Datenschutzbehörde binnen 72 Stunden).
Auch wenn keine Kompromittierung festgestellt wurde, empfiehlt sich eine dokumentierte Risikobeurteilung: Festhalten, dass die Schwachstelle bekannt war, welche Maßnahmen wann ergriffen wurden und warum kein meldepflichtiger Vorfall vorliegt. Diese Dokumentation ist bei einer späteren Prüfung durch Aufsichtsbehörden oder im Rahmen eines ISMS-Audits relevant.
§391 SGB V und B3S Krankenhaus
Für Krankenhäuser, die nach §391 SGB V zur Umsetzung angemessener IT-Sicherheitsmaßnahmen verpflichtet sind, ist das zeitnahe Patchen kritischer Schwachstellen in der MDM-Infrastruktur eine klare Anforderung. Der branchenspezifische Sicherheitsstandard (B3S) für die Gesundheitsversorgung im Krankenhaus benennt Patch-Management und Schwachstellenmanagement als eigenständige Maßnahmenfelder. Die aktive Ausnutzung dieser Ivanti EPMM Sicherheitslücke durch Angreifer unterstreicht, dass es sich nicht um ein theoretisches Risiko handelt.
Hinweis: Für konkrete rechtliche Einschätzungen zu Meldepflichten und Haftungsfragen wenden Sie sich an einen auf IT- und Gesundheitsrecht spezialisierten Rechtsanwalt.
Checkliste: Sofortmaßnahmen auf einen Blick
| Maßnahme | Priorität | Verantwortlich |
|---|---|---|
| Ivanti EPMM-Version prüfen, Patch einspielen | Sofort | IT-Betrieb |
| Erkennungsskript (aktualisierte Version) ausführen | Sofort | IT-Betrieb / IT-Sicherheit |
| Netzwerkzugriff auf EPMM-Konsole restriktieren | Sofort | Netzwerk-Team |
| Logs sichern und auf IoCs prüfen | Heute | IT-Sicherheit / SOC |
| SIEM-Integration EPMM-Logs prüfen / einrichten | Diese Woche | IT-Sicherheit |
| Risikobeurteilung dokumentieren | Diese Woche | ISB / CISO |
| Bei Verdacht: IR-Plan aktivieren, BSI-Meldung prüfen | Unverzüglich bei Fund | CISO / ISB |
| Awareness: IT-Betrieb über Angriffsmuster informieren | Diese Woche | ISB |
Strukturelles Problem: MDM als blinder Fleck im Schwachstellenmanagement
Der Fall Ivanti EPMM ist kein Einzelfall – er folgt einem wiederkehrenden Muster: Netzwerk-nahe Appliances und Management-Plattformen (MDM, VPN-Gateways, Firewall-Management) werden im Schwachstellenmanagement vieler Organisationen schlechter abgedeckt als klassische Server-Betriebssysteme. Gründe dafür sind unter anderem fehlende Integration in Vulnerability-Scanner, komplexere Patch-Prozesse bei Appliances und die falsche Annahme, diese Systeme seien "nicht direkt exponiert".
Für CISO und ISB empfiehlt sich eine kritische Überprüfung:
- Sind alle Appliances im Asset-Inventar vollständig erfasst? Netzwerkgeräte, MDM-Systeme, VPN-Gateways, Backup-Appliances – alle müssen im CMDB und im Schwachstellenmanagement-Prozess berücksichtigt sein.
- Werden BSI-Sicherheitsmitteilungen systematisch ausgewertet? Das BSI publiziert Sicherheitswarnungen für kritische Infrastrukturen über seinen Feed; die Integration in den Triage-Prozess des Security Operations-Teams ist eine Grundanforderung.
- Ist der Eskalationspfad für kritische 0-Days definiert? Ein CVSS-Score von 9.8 mit bestätigter aktiver Ausnutzung muss einen definierten Notfall-Patch-Prozess auslösen – außerhalb regulärer Change-Management-Zyklen.
Wenn Sie Ihren aktuellen Stand bei diesen Themen einschätzen möchten, bietet ISMShield.ai unter ismshield.bpcgmbh.com/assessment/ eine strukturierte Selbstbewertung für Krankenhäuser an.
Weitere Hintergrundartikel zu verwandten Themen finden Sie im ISMShield Wissenszentrum.