KritischCVE-2025-22457

    Ivanti Connect Secure: Stack-basierter Pufferüberlauf (CVE-2025-22457)

    Veröffentlicht In CISA KEV seit Quellen: SingCERT, NCSC NZ, pwn.watch, CVE.org

    Was ist betroffen, was ist zu tun

    Ein Stapel-basierter Pufferüberlauf in Ivanti Connect Secure vor Version 22.7R2.6, Ivanti Policy Secure vor Version 22.7R1.4 und Ivanti ZTA Gateways vor Version 22.8R2.2 ermöglicht es einem entfernten unauthentifizierten Angreifer, eine Ferncodeausführung zu erreichen.

    Die Schwachstelle wird aktiv ausgenutzt; behandeln Sie sie vorrangig. CISA führt sie als in Ransomware-Kampagnen genutzte Schwachstelle. Aktualisieren Sie Ivanti Connect Secure auf Version 22.7R2.6, Ivanti Policy Secure auf Version 22.7R1.4, Ivanti Neurons for ZTA gateways auf Version 22.8R2.2. Sofortmaßnahmen, Mitigation und Erkennungsregeln stehen im Runbook unten.

    Betroffen
    • Ivanti Connect Secure lt *..22.7R2.6
    • Ivanti Policy Secure lt *..22.7R1.4
    • Ivanti Neurons for ZTA gateways lt *..22.8R2.2
    Behoben in
    • Ivanti Connect Secure 22.7R2.6
    • Ivanti Policy Secure 22.7R1.4
    • Ivanti Neurons for ZTA gateways 22.8R2.2

    Unklar, ob und wie Sie betroffen sind? Frage zu dieser Schwachstelle stellen

    Metriken

    9,0

    Priorität

    XIEM Effective CVSS: höchste verfügbare CVSS-Bewertung aus NVD- und Herstellerangaben.

    Quelle: NVD, CVSS v3

    9,0

    CVSS v3

    Schweregrad Kritisch auf der Skala von 0 bis 10.

    Quelle: SingCERT, NCSC NZ, pwn.watch, CVE.org

    99,98 %

    EPSS-Score

    Hoch – Modell schätzt ≥ 50 % Chance auf reale Ausnutzung in 30 Tagen.

    Quelle: FIRST EPSS, Perzentil 99,98

    Alle Metriken anzeigen
    Schweregrad
    Kritisch
    Priorität (0–325)

    Der Priorisierungs-Score ist eine zusammengeführte Kennzahl, die mehrere Einzelsignale zu einer einzigen, handlungsleitenden Rangfolge verdichtet: technische Schwere (CVSS), Ausnutzungswahrscheinlichkeit (EPSS), der Status als bekannt ausgenutzt (KEV) und der Kontext des betroffenen Assets. Ziel ist die Antwort auf die einzig wirklich wichtige Frage im Schwachstellenmanagement: Was zuerst?

    Im Glossar lesen
    258.44 Methodik
    Exploit-Reife

    Ein Exploit ist Code oder eine Technik, die eine konkrete Schwachstelle gezielt ausnutzt, um ein unbeabsichtigtes Verhalten zu erzwingen — etwa Code auszuführen oder Rechte auszuweiten. Er ist das Werkzeug, das aus einer theoretischen Lücke einen praktischen Angriff macht.

    Im Glossar lesen
    aktiv ausgenutztQuelle: VulnCheck KEV (öffnet in neuem Tab), ANSSI / CERT-FR, NCSC NZ, CSA/SingCERT So stufen wir ein
    XIEM Effective CVSS

    XIEM® ist das gestufte Managed-Security-Betriebsmodell von NEOSEC und eine eingetragene Marke der NEOSEC GmbH. Es erweitert klassisches SIEM — die zentrale Sammlung, Normalisierung und Korrelation sicherheitsrelevanter Ereignisse — um Endpunkt-Forensik, Netzwerk-Sichtbarkeit und Täuschungstechnik und führt diese zu drei aufeinander aufbauenden Stufen zusammen: Sentry, Orchestrate und Command.

    Im Glossar lesen
    9,0 Methodik
    CVSS v3

    CVSS ist der weltweit verbreitete, offene Standard zur Bewertung der technischen Schwere einer Schwachstelle auf einer Skala von 0 bis 10. Er beschreibt, wie leicht eine Lücke ausnutzbar ist und welchen Schaden sie anrichten kann — nicht jedoch, wie wahrscheinlich ihre tatsächliche Ausnutzung ist. CVSS und das ergänzende EPSS beantworten bewusst unterschiedliche Fragen.

    Im Glossar lesen
    9,0
    EPSS-Score

    Der EPSS-Score ist der absolute Modell-Output für eine einzelne Schwachstelle: die geschätzte Wahrscheinlichkeit einer realen Ausnutzung in den nächsten 30 Tagen, ausgedrückt als Wert zwischen 0 und 1 (bzw. 0 % bis 100 %). Ein Score von 0,42 bedeutet „das Modell schätzt eine 42-prozentige Chance auf reale Ausnutzung binnen 30 Tagen“.

    Im Glossar lesen
    99,98 %
    Hoch – Modell schätzt ≥ 50 % Chance auf reale Ausnutzung in 30 Tagen.
    EPSS-Perzentil

    Das EPSS-Perzentil ist die relative Einordnung einer Schwachstelle innerhalb aller EPSS-bewerteten CVEs, ausgedrückt als Wert zwischen 0 und 1. Ein Perzentil von 0,90 bedeutet „diese CVE hat einen höheren EPSS-Score als 90 % aller anderen bewerteten CVEs“. Anders als der EPSS-Score ist es keine Wahrscheinlichkeit — sondern eine Positionierung im Ranking.

    Im Glossar lesen
    99,98
    Kritisch – CVE liegt im obersten Fünftel aller heute bewerteten CVEs (Rang ≥ 80 %).
    KEV-Status

    Der KEV-Katalog ist eine von der US-Behörde CISA gepflegte Liste von Schwachstellen, für die eine aktive Ausnutzung in der Praxis nachgewiesen ist. Er beantwortet nicht die Frage „wie schwer?“, sondern „wird es bereits angegriffen?“ — und priorisiert damit das Patchen scharf.

    Im Glossar lesen
    Aktiv ausgenutzt
    Veröffentlicht
    In CISA KEV seit

    Der KEV-Katalog ist eine von der US-Behörde CISA gepflegte Liste von Schwachstellen, für die eine aktive Ausnutzung in der Praxis nachgewiesen ist. Er beantwortet nicht die Frage „wie schwer?“, sondern „wird es bereits angegriffen?“ — und priorisiert damit das Patchen scharf.

    Im Glossar lesen
    CWE

    CWE ist ein Katalog typischer Schwächen-Arten in Software und Hardware — etwa fehlerhafte Eingabevalidierung, unsichere Speicherbehandlung oder mangelhafte Authentisierung. Während eine CVE eine konkrete Schwachstelle in einem konkreten Produkt benennt, beschreibt eine CWE die zugrunde liegende Fehlerklasse.

    Im Glossar lesen
    CWE-121

    Behebung und Mitigation

    Warum sofort handeln?

    Priorisierung

    Ein nicht authentifizierter Angreifer kann die Schwachstelle über das Netzwerk ausnutzen und auf einem Perimetersystem Code ausführen. Ein Scope-Wechsel ermöglicht vollständige Kompromittierung, die hohe Angriffskomplexität hat Angreifer in der Praxis jedoch nicht aufgehalten. Die Ausnutzungswahrscheinlichkeit gehört zu den höchsten aller bekannten CVEs, und CISA kennzeichnet eine Nutzung in Ransomware-Kampagnen. Bevorzugte Ziele sind VPN-Gateways von Behörden, KRITIS-Betreibern und Mittelständlern, weil sie direkten Zugang zu AD-Zugangsdaten und internen Netzen bieten. Jede internetexponierte Instanz unterhalb der genannten Fix-Versionen ist als höchste Priorität (Notfall-Change) zu behandeln und bis zum Beweis des Gegenteils als potenziell kompromittiert anzusehen; gegebenenfalls ist das NIS2-Meldeverfahren zu prüfen.

    1. Schritt 1 im Runbook

      Sofort-Response (0-24 h)

      • Version prüfen und patchen: Ivanti Connect Secure auf 22.7R2.6 oder neuer, Policy Secure auf 22.7R1.4 oder neuer und ZTA Gateways auf 22.8R2.2 oder neuer aktualisieren. Gilt für alle Appliances, auch Standby-Knoten in Clustern. Ältere Release-Linien, die keinen Hersteller-Support mehr erhalten, bekommen keinen Fix. Sie sind außer Betrieb zu nehmen oder umgehend zu migrieren; den Support-Status bitte im Vendor-Advisory nachschlagen.
      • Kompromittierung vor dem Patch ausschließen: Vor und nach dem Update den externen Integrity Checker Tool (ICT) von Ivanti ausführen. Zusätzlich die Logs auf Absturzmeldungen des Webdienstes sichten. Ein Patch entfernt keine bereits implantierte Persistenz.
      • Bei Kompromittierungsverdacht isolieren: Die Appliance vom Netz nehmen, forensische Images bzw. Snapshots sichern und einen Werksreset (Factory Reset) durchführen. Danach auf der gepatchten Version neu aufsetzen, statt das System „in-place" zu bereinigen.
      • Zugangsdaten und Schlüsselmaterial rotieren: Bei Verdacht auf Kompromittierung folgende Werte erneuern:
        • lokale Admin-Kennwörter,
        • Kennwörter von LDAP/AD-Bind- und Service-Konten der Appliance,
        • Zertifikate inklusive privater Schlüssel,
        • API-Keys. Zusätzlich alle aktiven VPN-Sitzungen beenden und MFA-Neuregistrierungen auf Auffälligkeiten prüfen.
      • Folgezugriffe im internen Netz untersuchen: Anmeldungen der Service-Konten der Appliance an Domänencontrollern und Servern im Zeitraum seit dem 2025-03 prüfen und gegebenenfalls Konten sperren.

    2. Schritt 2 im Runbook

      Mitigation-Layer

      • Netzsegmentierung: Die Admin-Oberfläche ausschließlich über ein dediziertes Management-Interface bzw. VLAN erreichbar machen; niemals über das externe Interface. Ausgehende Verbindungen der Appliance per Firewall auf notwendige Ziele begrenzen (AD/LDAP, RADIUS, NTP, DNS, Update-Server). Die Appliance braucht keinen freien Internet-Egress.
      • Exposition reduzieren: Ist ein sofortiges Patchen unmöglich, den Zugriff auf TCP 443 des Gateways temporär per Geo-IP- oder Allowlist-Regel einschränken. Bei hohem Risiko den Dienst abschalten und auf eine alternative Fernzugriffslösung ausweichen.
      • WAF/IPS vor dem Gateway: HTTP-Requests mit anormal langen Header-Werten an das Portal verwerfen. Öffentliche Analysen beschreiben überlange X-Forwarded-For-Werte als Auslöser. Signaturen des IPS-Herstellers für CVE-2025-22457 aktivieren und im Blockiermodus betreiben.
      • IAM/Least Privilege: Das LDAP-Bind-Konto der Appliance auf reine Leserechte beschränken und nicht in privilegierte Gruppen aufnehmen. Interne Zugriffe aus dem VPN-Adresspool per Firewall auf tatsächlich benötigte Ziele begrenzen (Zero-Trust-Prinzip).
      • Logging härten: Syslog der Appliance in Echtzeit an ein externes SIEM weiterleiten, da Angreifer lokale Logs manipulieren oder löschen können.

    3. Schritt 3 im Runbook

      Detection-Regeln

      • Webserver-/Proxy-Logs: Requests an das Gateway mit ungewöhnlich langen X-Forwarded-For-Headern aus Ziffern und Punkten, insbesondere mehrfach in kurzer Folge von derselben Quelle. Beispiel in SPL: index=proxy dest=<ivanti_vip> | eval xff_len=len(http_x_forwarded_for) | where xff_len>50
      • Appliance-Systemlogs: Absturz- bzw. Neustartmeldungen des Webprozesses (Segfaults, Core Dumps). Sie sind typische Spuren fehlgeschlagener Exploit-Versuche. Zusätzlich auf ICT-Ergebnisse mit „mismatched" oder „new files" sowie auf unerwartete Log-Lücken achten.
      • Netzwerktelemetrie (Zeek/Suricata): Ausgehende Verbindungen der Appliance zu unbekannten externen IPs bzw. VPS-Anbietern sowie Verbindungen zu ungewöhnlichen Zielports. Beispiel in KQL: CommonSecurityLog | where SourceIP in (ivanti_ips) and not(DestinationIP in (allowlist)) and DeviceAction == "allow"
      • Active Directory: Event IDs 4624/4625 und 4768/4769 für das Service-Konto der Appliance von Quellen außerhalb der Appliance-IPs sowie LDAP-Massenabfragen von der Appliance-IP (Event 1644 mit aktiviertem LDAP-Logging).
      • EDR im internen Netz: Lateral Movement mit Quell-IPs aus dem VPN-Pool, etwa Remote-Service-Erstellung (Event 7045), WMI- oder PsExec-Muster sowie RDP auf Server ohne zugehöriges Change-Ticket.

    Erkennungsregeln

    Für diese Schwachstelle liegt noch keine NEOSEC-Erkennungsregel vor.

    Einordnung nach NIS2 und CRA

    Regelbasierte Einordnung aus Ausnutzungsstatus und Schweregrad. Sie ersetzt keine Prüfung im Einzelfall.

    NIS2

    NIS2 ist die EU-Richtlinie (EU) 2022/2555 zur Erhöhung des Cybersicherheitsniveaus in der Union. Sie weitet Pflichten gegenüber der ersten NIS-Richtlinie deutlich aus: mehr Sektoren, verbindliches Risikomanagement, gestufte Meldepflichten und persönliche Verantwortung der Geschäftsleitung.

    Im Glossar lesen
    Aktiv ausgenutzt: Behandeln Sie die Schwachstelle im Schwachstellenmanagement nach Art. 21 Abs. 2 lit. e NIS2 vorrangig. Wird sie in Ihrer Umgebung ausgenutzt, prüfen Sie die Meldepflicht nach Art. 23 (Frühwarnung binnen 24 Stunden).
    CRA

    Der CRA ist die EU-Verordnung (EU) 2024/2847 mit horizontalen Cybersicherheitsanforderungen an „Produkte mit digitalen Elementen“ — von Industriesteuerungen über Software bis zu vernetzten Verbrauchergeräten. Erstmals müssen Hersteller Sicherheit über den gesamten Produktlebenszyklus gewährleisten, Schwachstellen behandeln und Sicherheitsupdates bereitstellen.

    Im Glossar lesen
    Seit dem 11.09.2026 müssen Hersteller betroffener Produkte mit digitalen Elementen aktiv ausgenutzte Schwachstellen nach Art. 14 CRA melden, mit Frühwarnung binnen 24 Stunden über die zentrale Meldeplattform der ENISA.
    ISO/IEC 27001

    ISO/IEC 27001 ist der international führende Standard für ein Informationssicherheits-Managementsystem (ISMS). Er beschreibt einen risikobasierten, prozessorientierten Rahmen, um Informationssicherheit systematisch zu planen, umzusetzen, zu überprüfen und zu verbessern.

    Im Glossar lesen
    Maßnahme A.8.8, Management technischer Schwachstellen: Relevanz für Ihre Systeme bewerten, Behebung einplanen und nachweisen.

    Beschreibung

    Ein Stapel-basierter Pufferüberlauf in Ivanti Connect Secure vor Version 22.7R2.6, Ivanti Policy Secure vor Version 22.7R1.4 und Ivanti ZTA Gateways vor Version 22.8R2.2 ermöglicht es einem entfernten unauthentifizierten Angreifer, eine Ferncodeausführung zu erreichen.

    Originalquelle nur englisch verfügbar, maschinell ins Deutsche übersetzt.

    Quelle: CSA/SingCERT, NCSC NZ (CC BY 4.0), pwn.watch, CISA KEV Catalog, cvelistv5, NVD (NIST), CVE.org (MITRE)

    Betroffene Produkte

    Betroffen sind die folgenden Versionen. Ältere Stände derselben Reihe sind ebenfalls verwundbar, sofern nicht anders angegeben.

    Betroffene Produkte
    Betroffene VersionenBehoben in
    IvantiConnect Secure
    • < 22.7R2.6
    • 22.7R2.6
    IvantiNeurons for ZTA gateways
    • < 22.8R2.2
    • 22.8R2.2
    IvantiPolicy Secure
    • < 22.7R1.4
    • 22.7R1.4
    ivanticonnect_secure
    • 22.7
    • < 22.7
    • —
    • 22.7
    ivantipolicy_secure
    • 22.7
    • < 22.7
    • —
    • 22.7
    ivantizero_trust_access_gateway
    • < 22.8
    • 22.8
    • 22.8
    • —

    Hersteller und Produkte

    Weakness-Klassen (CWE)

    • CWE-121Stack-based Buffer Overflow

      Variant

      A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function).

      Eintrag bei MITRE CWE-121

    Öffentliche Exploit-Referenzen

    Öffentlich gemeldete Proof-of-Concepts, Exploit-Module und Detection-Templates zu dieser Schwachstelle. NEOSEC verlinkt ausschließlich auf die Originalquellen und stellt keinen Exploit-Code bereit.

    Öffentliche Exploit-Referenzen
    CISA KEV CatalogCISA Known Exploited Vulnerability (öffnet in neuem Tab)cisa.govaktiv ausgenutzt
    CSA/SingCERTOngoing Campaign Targeting Ivanti Products (öffnet in neuem Tab)CSA/SingCERTaktiv ausgenutzt
    NCSC NZCVE-2025-22457 affecting certain Ivanti products (öffnet in neuem Tab)NCSC NZaktiv ausgenutzt
    ANSSI / CERT-FRLicence Ouverte 2.0, Stand CERTFR-2025-ALE-003 – [MàJ] Vulnérabilité dans les produits Ivanti (clôturée 2025-06-24) (öffnet in neuem Tab)cert.cyber.gouv.fraktiv ausgenutzt
    PoC-in-GitHub (nomi-sec)cve-2025-22457 (öffnet in neuem Tab)github.comPoC (öffentlich gemeldet)gemeldet, nicht verifiziert

    Quellen & Referenzen

    • forums.ivanti.comIvanti advisory: Ivanti Connect Secure, Policy Secure, and ZTA Gatewayspwn-watch
    • cisa.govknown-exploited-vulnerabilities-catalog?field_cve=CVE-2025-22457government-resource
    • cert.cyber.gouv.frANSSI / CERT-FR: CERTFR-2025-ALE-003 – [MàJ] Vulnérabilité dans les produits Ivanti (clôturée 2025-06-24)cert-fr
    • pwn.watchpwn.watch: Ivanti Connect Secure, Policy Secure, and ZTA Gateways: Connect Secure, Policy Secure, and ZTA Gateways Stack-Based Buffer Overflow Vulnerabilitypwn-watch
    • cisa.govCISA guidance: Ivanti Connect Secure, Policy Secure, and ZTA Gatewayspwn-watch
    • NVD (NIST)NVD: CVE-2025-22457pwn-watch
    • cisa.govCISA Known Exploited Vulnerabilities Catalogpwn-watch
    Badge einbetten

    Zeigen Sie Schweregrad und KEV-Status dieser Schwachstelle auf Ihrer Seite – mit Link hierher. Das Bild wird stündlich aktualisiert.

    Badge-Vorschau für CVE-2025-22457
    <a href="https://intel.neosec.eu/cve/CVE-2025-22457"><img src="https://intel.neosec.eu/badge/cve/CVE-2025-22457.svg" alt="CVE-2025-22457 – NEOSEC Intel" height="20"></a>