KritischCVE-2025-48384

    Git: Folgen symbolischer Links (Link Following) (CVE-2025-48384)

    Veröffentlicht Zuletzt geändert In CISA KEV seit Quellen: Debian LTS, pwn.watch, Red Hat, Msrc Update Guide, CVE.org, OSV

    Was ist betroffen, was ist zu tun

    CVE-2025-48384 betrifft Bitnami Git und kombiniert eine Interpretation-Inkonsistenz (CWE-436) mit einem Link-Following-Angriff (CWE-59), was einem authentifizierten Angreifer unter bestimmten Bedingungen ermöglicht, Dateisystemoperationen außerhalb des vorgesehenen Verzeichnisses durchzuführen und potenziell vollständige Kontrolle über das betroffene System zu erlangen. Der Angriff erfordert eine Benutzerinteraktion sowie erhöhte Netzwerkkomplexität, ist jedoch über das Netzwerk ausführbar. Die Schwachstelle wird aktiv in freier Wildbahn ausgenutzt und wurde von CISA in den Known Exploited Vulnerabilities Catalog aufgenommen, was eine unmittelbare Reaktion erfordert. Betroffene Organisationen sollten die verfügbaren Patches für Bitnami Git umgehend einspielen, da aktive Ausnutzung bestätigt ist.

    Die Schwachstelle wird aktiv ausgenutzt; behandeln Sie sie vorrangig. Aktualisieren Sie Git auf Version 2.43.7. Sofortmaßnahmen, Mitigation und Erkennungsregeln stehen im Runbook unten.

    Betroffen
    • Git gte 2.44.0-rc0, < 2.44.4..*
    • Git lt *..2.43.7
    Behoben in
    • Git 2.43.7

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

    Metriken

    8,1

    Priorität

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

    Quelle: Hersteller (CNA), CVSS v3

    8,1

    CVSS v3

    Schweregrad Hoch auf der Skala von 0 bis 10.

    Quelle: Debian LTS, pwn.watch, Red Hat, Msrc Update Guide, CVE.org, OSV

    4,4 %

    EPSS-Score

    Moderat – Modell schätzt 1-10 % Ausnutzungs-Wahrscheinlichkeit.

    Quelle: FIRST EPSS, Perzentil 91,2

    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
    216.88 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) 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
    8,1 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
    8,1
    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
    4,4 %
    Moderat – Modell schätzt 1-10 % Ausnutzungs-Wahrscheinlichkeit.
    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
    91,2
    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-436, CWE-59

    Behebung und Mitigation

    Warum sofort handeln?

    Priorisierung

    Die Schwachstelle ermöglicht Codeausführung auf dem System, das ein präpariertes Repository rekursiv klont. Sie ist damit ein klassischer Hebel gegen die Software-Lieferkette, der gezielt Entwickler-Arbeitsplätze und CI/CD-Infrastruktur trifft. Die Ausnutzung erfordert Benutzerinteraktion und eine gewisse Angriffskomplexität. Durch den Scope-Wechsel reicht die Wirkung jedoch über Git hinaus, und die Ausnutzungswahrscheinlichkeit liegt deutlich über dem Durchschnitt aller CVEs. Eine Ransomware-Nutzung ist laut CISA nicht bekannt. Für Organisationen mit eigener Softwareentwicklung, selbst gehosteten Runnern oder macOS-Entwicklerflotten gilt hohe Priorität (Patch innerhalb weniger Tage, CI-Runner sofort); reine Anwender-Umgebungen ohne Git-Nutzung können regulär im Patchzyklus nachziehen.

    1. Schritt 1 im Runbook

      Sofort-Response (0-24 h)

      • Git auf allen Entwickler-Arbeitsplätzen, Build-Servern und CI/CD-Runnern aktualisieren auf eine der korrigierten Versionen: v2.43.7, v2.44.4, v2.45.4, v2.46.4, v2.47.3, v2.48.2, v2.49.1 oder v2.50.1. Bestand prüfen mit git --version. Priorität haben macOS- und Linux-Systeme, da der Angriff Symlinks und ein Carriage Return (CR) im Submodul-Pfad voraussetzt.
      • Gebündelte Git-Installationen nicht vergessen: Apple Xcode auf 26.0 aktualisieren (enthält den Fix). IDEs, GUI-Clients und Container-Images mit eigenem Git-Binary separat inventarisieren. Für Debian 11 das Distributions-Sicherheitsupdate einspielen — Paketversion bitte im Debian-Security-Advisory nachschlagen.
      • Rekursives Klonen fremder Repositories sofort untersagen: Bis zum Abschluss des Patchens kein git clone --recurse-submodules, git submodule update --init oder git pull mit aktivem submodule.recurse auf Repositories aus nicht vertrauenswürdigen Quellen (Forks, externe Pull Requests, Code-Beispiele aus Foren).
      • CI/CD-Pipelines priorisieren: Pipelines, die externe Pull Requests oder Drittanbieter-Repositories mit Submodulen auschecken, pausieren oder auf gepatchte Runner-Images umstellen. Selbst gehostete Runner haben Vorrang, weil sie persistent sind und häufig Secrets vorhalten.
      • Kompromittierungsverdacht abklären: Wenn in den letzten Wochen untrusted Repositories rekursiv geklont wurden, auf den betroffenen Hosts SSH-Schlüssel, Git-Tokens (PATs), Cloud-Credentials und Signierschlüssel rotieren. Shell-Profile und LaunchAgents/systemd-User-Units auf Persistenz prüfen.

    2. Schritt 2 im Runbook

      Mitigation-Layer

      • Konfigurationshärtung (Client): Global git config --global submodule.recurse false setzen und per MDM bzw. Konfigurationsmanagement (Ansible, Jamf, Intune) verteilen. Zusätzlich kann git config --global core.hooksPath /etc/git/empty-hooks auf ein leeres, root-eigenes Verzeichnis gesetzt werden. Das unterbindet die Hook-Ausführung in Submodulen, bricht aber hook-basierte Workflows (z. B. husky, pre-commit). Diese Workflows vorher abstimmen.
      • Repository-Eingangskontrolle (Server-seitig): Auf GitLab-, Gitea- oder Bitbucket-Servern einen Pre-Receive-Hook einsetzen, der Pushes mit .gitmodules-Einträgen ablehnt, die auf CR enden (grep -nP '\r$' .gitmodules). Gleiches gilt für Symlinks (Mode 120000), deren Ziel .git/modules oder hooks enthält.
      • Manuelle Prüfung vor dem Klonen: Fremde Repositories zunächst ohne Submodule klonen. Danach Rohdaten prüfen: grep -nP '\r$' .gitmodules sowie git ls-files -s | awk '$1=="120000"'. Wichtig: git config -f .gitmodules eignet sich wegen genau dieses Fehlers nicht zur Prüfung, da Git das CR beim Lesen entfernt.
      • Isolation der Build-Umgebung: CI-Runner ephemer betreiben (Wegwerf-Container/VM pro Job), ohne langlebige Secrets und mit restriktivem Egress (Allowlist für Artefakt-Registries und Git-Server). Externe Pull Requests nur in Pipelines ohne Zugriff auf Deployment-Credentials bauen.
      • Least Privilege: Entwickler-Konten ohne lokale Administratorrechte betreiben. Git-Tokens auf minimale Scopes und kurze Laufzeiten beschränken, damit eine Codeausführung im Benutzerkontext begrenzte Reichweite hat.

    3. Schritt 3 im Runbook

      Detection-Regeln

      • EDR-Prozessabfolge: git → sh/bash/zsh → curl/wget/python/osascript/nc, wobei die Kommandozeile /.git/modules/ und hooks/post-checkout enthält. KQL-Beispiel: DeviceProcessEvents | where InitiatingProcessFileName =~ "git" and ProcessCommandLine has "hooks/post-checkout".
      • Linux auditd / Sysmon for Linux (EID 1): execve-Ereignisse, deren exe oder cwd auf */.git/modules/*/hooks/post-checkout passt. Als Sigma-Form: logsource: linux/process_creation, selection: ParentImage|endswith: '/git', CommandLine|contains: '/hooks/post-checkout'.
      • Dateisystem-Indikatoren: Verzeichnisse oder Symlinks, deren Name auf CR (\r) endet. Hunting-Befehl auf Endpunkten: find ~ -name $'*\r' 2>/dev/null. Zusätzlich auf Symlinks innerhalb von Arbeitskopien achten, die auf .git/modules/*/hooks zeigen.
      • Netzwerk-Telemetrie (Zeek/Suricata): Auffällige ausgehende Verbindungen von Build-Runnern oder Entwickler-Hosts unmittelbar nach Git-Klonvorgängen, etwa zu unbekannten Domains oder Paste-/File-Sharing-Diensten. Korrelieren Sie dazu den Git-Traffic (HTTPS/443, SSH/22) mit nachfolgendem Egress innerhalb weniger Sekunden.
      • Git-Server-Logs: Pushes, die neue .gitmodules-Einträge und gleichzeitig Symlinks enthalten, sowie Abweisungen durch den oben genannten Pre-Receive-Hook. Beide Ereignisse als Alarm in das SIEM weiterleiten.

    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

    Git ist ein schnelles, skalierbares verteiltes Versionskontrollsystem mit einem ungewöhnlich reichen Satz an Befehlen, der sowohl hochrangige Operationen als auch vollständigen Zugriff auf die Interna bietet. Beim Lesen eines Konfigurationswerts entfernt Git jedes abschließende Wagenrücklaufzeichen (CR) und Zeilenende (LF). Beim Schreiben einer Konfigurationseintragung werden Werte mit einem abschließenden CR nicht zitiert, wodurch das CR verloren geht, wenn die Konfiguration später gelesen wird. Beim Initialisieren eines Submoduls, wenn der Pfad des Submoduls ein abschließendes CR enthält, wird der geänderte Pfad gelesen und das Submodul in einem falschen Verzeichnis eingecheckt. Wenn ein Symbollink existiert, der den geänderten Pfad auf das Verzeichnis für die Submodulknoten zeigt, und das Submodul einen ausführbaren post-checkout-Knoten enthält, kann das Skript unbeabsichtigt nach dem Einchecken ausgeführt werden. Diese Sicherheitslücke wird in den Versionen v2.43.7, v2.44.4, v2.45.4, v2.46.4, v2.47.3, v2.48.2, v2.49.1 und v2.50.1 behoben.

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

    Quelle: Debian LTS Advisories, pwn.watch, redhat_csaf, Microsoft Security Update Guide, NVD (NIST), OSV (Open Source Vulnerabilities), cvelistv5, CISA KEV Catalog, 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
    gitgit
    • ≥ 2.44.0-rc0, < 2.44.4
    • < 2.43.7
    • —
    • 2.43.7
    applexcode
    • < 26.0
    • 26.0
    git-scmgit
    • 2.46.0 – < 2.46.4
    • 2.45.0 – < 2.45.4
    • 2.44.0 – < 2.44.4
    • 2.47.0 – < 2.47.3
    • 2.48.0 – < 2.48.2
    • 2.49.0 – < 2.49.1
    • 2.50.0 – < 2.50.1
    • < 2.43.7
    • 2.46.4
    • 2.45.4
    • 2.44.4
    • 2.47.3
    • 2.48.2
    • 2.49.1
    • 2.50.1
    • 2.43.7

    Hersteller und Produkte

    Betroffene Betriebssysteme

    Betroffene Betriebssysteme
    Linuxdebiandebian_linux11.0
    Linuxdebiangitbullseye

    Weakness-Klassen (CWE)

    • CWE-436Interpretation Conflict

      Class

      Product A handles inputs or steps differently than Product B, which causes A to perform incorrect actions based on its perception of B's state.

      Eintrag bei MITRE CWE-436

    • CWE-59Improper Link Resolution Before File Access ('Link Following')

      Base

      The product attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource.

      Eintrag bei MITRE CWE-59

    Ö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
    PoC-in-GitHub (nomi-sec)devin-cve48384-1789318364-1162143-parent (öffnet in neuem Tab)github.comPoC (öffentlich gemeldet)gemeldet, nicht verifiziert
    PoC-in-GitHub (nomi-sec)gitssrf-gim-cve-parent (öffnet in neuem Tab)github.comPoC (öffentlich gemeldet)gemeldet, nicht verifiziert
    PoC-in-GitHub (nomi-sec)cve-2025-48384 (öffnet in neuem Tab)github.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).

    Eine Übersetzung der NVD in eine andere Sprache ist ausgeblendet.

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