KritischCVE-2021-42237

    Sitecore XP: Deserialisierung nicht vertrauenswürdiger Daten (CVE-2021-42237)

    Veröffentlicht Zuletzt geändert In CISA KEV seit Quellen: CVE.org

    Was ist betroffen, was ist zu tun

    Die Schwachstelle CVE-2021-42237 ermöglicht Remote-Code-Ausführung (RCE) durch unsichere Deserialisierung in Sitecore XP Versionen 7.5 bis 8.2 Update-7. Ein Angreifer kann ohne Authentifizierung oder spezielle Konfiguration auf dem betroffenen System beliebigen Code ausführen. Diese Schwachstelle wird aktiv in Ransomware-Kampagnen ausgenutzt. Unternehmen sollten dringend auf die neueste Version aktualisieren, um das Risiko zu minimieren.

    Die Schwachstelle wird aktiv ausgenutzt; behandeln Sie sie vorrangig. CISA führt sie als in Ransomware-Kampagnen genutzte Schwachstelle. Die vorliegenden Quellen nennen keine Fix-Version. Prüfen Sie die Herstellerhinweise in den Referenzen unten. Sofortmaßnahmen, Mitigation und Erkennungsregeln stehen im Runbook unten.

    Betroffen
    • Sitecore Experience Platform eq 7.5..7.5
    • Sitecore Experience Platform eq 8.0..8.0
    • Sitecore Experience Platform eq 8.1..8.1
    • Sitecore Experience Platform eq 8.2..8.2

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

    Metriken

    9,8

    Priorität

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

    Quelle: NVD, CVSS v3

    9,8

    CVSS v3

    Schweregrad Kritisch auf der Skala von 0 bis 10.

    Quelle: CVE.org

    97,6 %

    EPSS-Score

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

    Quelle: FIRST EPSS, Perzentil 99,90

    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
    253.84 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 ausgenutzt
    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,8 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,8
    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
    97,6 %
    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,90
    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
    CISA-Bewertung (SSVC)
    Ausnutzung: aktiv · automatisierbar · Auswirkung: vollständig
    Quelle: CISA Vulnrichment, Stand 3. Februar 2025
    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-502

    Behebung und Mitigation

    Warum sofort handeln?

    Priorisierung

    Die Schwachstelle ist ohne Authentifizierung, ohne Benutzerinteraktion und mit geringer Komplexität über das Netz ausnutzbar und führt direkt zur Codeausführung im Kontext des IIS-Arbeitsprozesses. Seit der Veröffentlichung eines Proof of Concept gehört sie zu den CVEs mit der höchsten Ausnutzungswahrscheinlichkeit überhaupt. CISA führt sie mit dem Vermerk bekannter Ransomware-Nutzung; typische Ziele sind öffentlich erreichbare Unternehmens- und Marketing-Websites, die oft von Agenturen betreut werden und als Altbestand unbeachtet weiterlaufen. Jede aus dem Internet erreichbare Instanz im betroffenen Versionsbereich ist als kritisch mit sofortigem Handlungsbedarf einzustufen und bis zum Nachweis des Gegenteils als potenziell kompromittiert zu behandeln. Rein intern erreichbare Instanzen sind innerhalb weniger Tage zu beheben.

    1. Schritt 1 im Runbook

      Sofort-Response (0-24 h)

      • Bestand erfassen: Alle Sitecore-XP-Instanzen (CM, CD, Staging, vergessene Test- oder Marketing-Microsites) mit Version 7.5 Initial Release bis 8.2 Update-7 identifizieren. Die Version steht in /sitecore/shell/sitecore.version.xml oder im Admin-Login-Banner. Auch extern gehostete Agentur-Instanzen einbeziehen.
      • Verwundbaren Handler entfernen: Den betroffenen Endpunkt /sitecore/shell/ClientBin/Reporting/Report.ashx auf allen betroffenen Instanzen sofort löschen oder umbenennen. Das ist die vom Hersteller empfohlene Sofortmaßnahme. Den Schritt in jede Deployment-Pipeline übernehmen, damit der Handler nicht wieder ausgerollt wird. Danach IIS-Recycle durchführen und den Endpunkt per HTTP prüfen: Erwartet wird 404.
      • Dauerhafte Behebung: Ein Upgrade auf eine nicht betroffene Sitecore-XP-Version planen. Der Patch ist beim Hersteller verfügbar — Version bitte im Vendor-Advisory von Sitecore nachschlagen. Die 7.x/8.x-Linie gilt als Altbestand und sollte grundsätzlich auf eine unterstützte Version migriert werden.
      • Kompromittierungsprüfung vor Rückkehr in den Normalbetrieb: War die Instanz aus dem Internet erreichbar, ist von möglicher Kompromittierung auszugehen. Webroot auf unbekannte .aspx, .ashx und .asmx sowie auf neue DLLs in \bin prüfen, IIS-Logs rückwirkend auswerten (siehe Detektion) und bei Treffern den forensischen Prozess nach Incident-Response-Plan auslösen.
      • Zugangsdaten rotieren — bei Verdacht oder fehlendem Ausschluss einer Kompromittierung: Connection-Strings in ConnectionStrings.config (SQL, MongoDB/xDB), Sitecore-Admin-Konten, Machine Key sowie die Kennwörter von Dienstkonten des IIS-AppPools.
      • Meldepflicht prüfen: Bei bestätigter Ausnutzung in NIS2-Einrichtungen die Frühwarnung an das BSI innerhalb von 24 h vorbereiten.

    2. Schritt 2 im Runbook

      Mitigation-Layer

      • Netzwerksegmentierung: Den Pfad /sitecore/shell/* und /sitecore/admin/* auf Content-Delivery-Servern grundsätzlich nicht aus dem Internet erreichbar machen. Den Zugriff auf CM-Server nur aus dem Redaktionsnetz bzw. über VPN mit IP-Allowlist erlauben.
      • WAF/Reverse-Proxy: Eine Regel einrichten, die Anfragen auf Report.ashx (case-insensitive, auch URL-kodiert und mit Pfadvarianten wie //, ;, %2e) blockiert. Zusätzlich POST-Bodies mit Deserialisierungs-Markern wie NetDataContractSerializer, ObjectDataProvider, System.Diagnostics.Process oder TypeConfuseDelegate verwerfen.
      • IPS: Suricata/Snort-Signaturen für HTTP-POST auf /sitecore/shell/ClientBin/Reporting/Report.ashx aktivieren, etwa ET-Regeln zu CVE-2021-42237. Die Signaturen im Blockiermodus vor die Webserver setzen.
      • Endpoint-Härtung: Per EDR- oder ASR-Regel verhindern, dass w3wp.exe Kindprozesse wie cmd.exe, powershell.exe, rundll32.exe oder certutil.exe startet. Schreibrechte der AppPool-Identität auf den Webroot entziehen; ausgenommen sind nur die notwendigen Verzeichnisse (App_Data, temp, upload).
      • Least Privilege: Den AppPool unter einer dedizierten, nicht privilegierten Identität betreiben. SQL-Logins des Sitecore-Kontos auf die benötigten Datenbanken beschränken (kein sysadmin, kein xp_cmdshell).
      • Egress-Filter: Ausgehende Verbindungen der Webserver auf notwendige Ziele beschränken. Das erschwert Reverse-Shells, das Nachladen von Payloads und C2-Kommunikation.

    3. Schritt 3 im Runbook

      Detection-Regeln

      • IIS-Access-Log: POST-Anfragen auf Report.ashx sind im Normalbetrieb praktisch nie legitim. SPL: index=iis cs_method=POST cs_uri_stem="*/ClientBin/Reporting/Report.ashx*" | stats count by c_ip, sc_status, cs_user_agent. Auch Antworten mit Status 200 oder 500 und großem cs_bytes beachten.
      • Prozessabstammung (Sysmon EID 1 / Security 4688): w3wp.exe startet cmd.exe, powershell.exe, whoami.exe, net.exe oder certutil.exe. KQL: DeviceProcessEvents | where InitiatingProcessFileName =~ "w3wp.exe" and FileName in~ ("cmd.exe","powershell.exe","whoami.exe","certutil.exe","rundll32.exe").
      • Webshell-Ablage (Sysmon EID 11): w3wp.exe erstellt .aspx-, .ashx-, .asmx- oder .dll-Dateien unterhalb des Sitecore-Webroots. Als Sigma-Form: Image|endswith: '\w3wp.exe' AND TargetFilename|endswith: ['.aspx','.ashx','.asmx'].
      • Netzwerk (Zeek/Suricata): Neue ausgehende Verbindungen von Sitecore-Servern zu unbekannten externen IPs kurz nach einem POST auf Report.ashx sind verdächtig, ebenso DNS-Anfragen an Out-of-band-Dienste (*.oast.*, *.burpcollaborator.net, *.interact.sh), die typisch für Scanning und Exploit-Verifikation sind.
      • Folgeaktivität: Prüfen auf Ausführung von LSASS-Dump-Werkzeugen, auf neue lokale Konten (EID 4720) sowie auf geplante Tasks (EID 4698) auf Webservern. Diese Muster passen zur Vorbereitung von Ransomware.

    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

    Die erste Veröffentlichung von Sitecore XP 7.5 bis zur Aktualisierung 7 von Sitecore XP 8.2 ist anfällig für einen unsicheren Deserialisierungsangriff, bei dem eine Fernbefehlsausführung auf der Maschine möglich ist. Es sind keine Authentifizierung oder spezielle Konfiguration erforderlich, um diese Schwachstelle auszunutzen.

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

    Quelle: CISA KEV Catalog, NVD (NIST), cvelistv5, 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
    sitecoreexperience_platform
    • 7.5
    • 8.0
    • 8.2
    • 8.1
    • —
    • —
    • —
    • —

    Hersteller und Produkte

    Weakness-Klassen (CWE)

    • CWE-502Deserialization of Untrusted Data

      Base

      The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid.

      Eintrag bei MITRE CWE-502

    Ö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
    Packet StormSitecore Experience Platform XP Remote Code Execution (öffnet in neuem Tab)packetstormsecurity.comPoC (öffentlich gemeldet)gemeldet, nicht verifiziert—

    Quellen & Referenzen

    Änderungen an der CVE

    Wer diese CVE wann geändert hat: die NVD (Analyse, betroffene Produkte, CVSS), der Herausgeber der CVE (CNA) und ergänzende Stellen wie CISA (ADP).

    1. Analyse der NVD geändertNVD

    2. Eintrag geändertMITRE

      2 Einzeländerungen: Referenz, Referenztyp

      2 Einzeländerungen im Original anzeigen
      Einzeländerungen dieses Ereignisses im Original der NVD
      ArtAktionVorherNachher
      Referenzentfernt
      http://sitecore.com
      —
      Referenztypentfernt
      http://sitecore.com Types: Vendor Advisory
      —

      Kennung der Quelle: cve@mitre.org

    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-2021-42237
    <a href="https://intel.neosec.eu/cve/CVE-2021-42237"><img src="https://intel.neosec.eu/badge/cve/CVE-2021-42237.svg" alt="CVE-2021-42237 – NEOSEC Intel" height="20"></a>