CVE-2025-48384: Git Link Following Vulnerability
Git contains a link following vulnerability that stems from Git’s inconsistent handling of carriage return characters in configuration files.
CVE-2025-48384 is a link-following vulnerability in Git that arises from inconsistent handling of carriage return characters in configuration files. An attacker who can influence those files may cause Git to resolve paths or links in unintended ways, potentially leading to unauthorized file access or modification on systems that use Git. This matters for development workstations, CI/CD runners, and any host that clones or operates on untrusted repositories, because Git is widely deployed and often runs with the privileges of the user or service account that invokes it. Confirm exact impact and affected releases against the vendor advisory.
How it works
The flaw is classified under CWE-59 (Improper Link Resolution Before File Access, or link following) and CWE-436 (Interpretation Conflict). Git’s configuration parsing treats carriage return characters inconsistently. That mismatch can allow a crafted configuration entry to steer Git toward following a symbolic link or path that the operator did not intend. In practical terms, an attacker who can place or modify a Git configuration file—commonly through a malicious repository, a shared config, or another write path—may cause subsequent Git operations to read from or write to locations outside the expected working tree. The precise trigger conditions and required attacker privileges are not detailed here; treat any repository or config source that is not fully trusted as a potential vector and verify the mechanics in the vendor advisory.
Am I affected? How to find it in your systems
Git runs on developer laptops, build servers, container images used for CI, and many Linux, macOS, and Windows hosts that perform source-control operations. Inventory every system that has the git binary installed or that executes Git as part of automation.
- Locate installations with package managers (for example, dpkg -l | grep git, rpm -q git, brew list git) or by searching PATH and common install directories.
- Record the version string returned by git --version on each host and compare it with the fixed versions listed in the vendor advisory; do not rely on version numbers stated elsewhere.
- Inspect Git configuration sources that may contain carriage-return characters: system-wide config, user ~/.gitconfig, repository .git/config, and any include paths or environment variables that override config.
- Review recent clones, fetches, or submodule updates from untrusted remotes; look for unexpected file writes outside the working tree or anomalous permission changes on configuration files.
- If centralized logging or EDR is available, search for Git processes that open files outside the repository root shortly after a config parse, or for creation of symbolic links in directories that Git later reads.
Absence of clear telemetry does not prove safety; confirm exposure status against the official advisory.
How to remediate
Apply the vendor-supplied update for Git as soon as it is available and tested in your environment. Follow the installation or package-update instructions published by the Git project or your distribution vendor. After patching, re-run git --version to confirm the new release is active on every host and rebuild any container images or golden images that embed Git.
As additional hardening for this class of issue:
- Restrict write access to Git configuration files and to directories that may be referenced by include directives.
- Prefer cloning and building untrusted code inside isolated containers or VMs that have no sensitive host mounts.
- Disable or tightly control features that automatically process remote configuration (for example, certain includeIf or credential-helper paths) if they are not required.
- Enforce code-review and signing policies so that malicious configuration content is less likely to reach production runners.
CISA guidance for this CVE is to apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable.
If you can't patch immediately
Until the vendor update can be deployed, reduce exposure with compensating controls:
- Segment development and CI networks so that compromised build hosts cannot reach high-value data stores or production credentials.
- Run Git operations for untrusted repositories under least-privilege accounts and inside ephemeral containers that discard state after each job.
- If a web application firewall or host-based policy engine can inspect Git traffic or file-system activity, add rules that block unexpected symlink creation or config writes containing anomalous control characters; treat such rules as temporary virtual patches and validate them carefully.
- Temporarily disable automatic processing of repository-local or included configuration when the workflow allows it, forcing use of a known-good system or user config only.
- Increase monitoring for Git process file-access anomalies and for new symbolic links appearing in directories that Git configuration may reference.
These measures lower risk but do not replace the official patch; schedule the update promptly.
If your data may have been exposed
Actively exploited vulnerabilities can lead to unauthorized access and data exposure. If you suspect that a malicious configuration or repository was processed by an unpatched Git instance, treat the host as potentially compromised: isolate it, preserve forensic evidence, rotate credentials that may have been accessible, and examine any files that Git may have written outside the intended tree. Known ransomware use of this CVE is not documented. You can also run a free exposure scan of your email addresses against known breach data sets to determine whether related accounts have already appeared in public dumps, then force password resets and enable multi-factor authentication where appropriate.
AICompiled with AI assistance from public sources and published under our editorial standards.