CVE-2025-48384 is a client-side Git vulnerability that lets a malicious repository abuse a mismatch in how Git reads vs. writes configuration values containing a trailing carriage return (\r). With a crafted .gitmodules file and a submodule path ending in \r, Git may check out submodule content to an unintended location.
Combined with a symlink into .git/hooks/ and an executable hook (e.g., post-checkout), this yields arbitrary file write and can lead to code execution after clone/checkout, most commonly when cloning with –recursive.
The flaw is now on CISA’s KEV list with evidence of in-the-wild exploitation. Patch immediately and harden developer workflows.
What’s vulnerable & fixed versions
Per the upstream advisory, patch to one of the following Git versions (or later): v2.43.7, v2.44.4, v2.45.4, v2.46.4, v2.47.3, v2.48.2, v2.49.1, v2.50.1. All earlier releases in those trains are affected. Distributions and developer tools that embed Git must update the embedded Git binary accordingly.
Note on platforms: Current write-ups indicate impact on macOS & Linux; Windows is not affected due to line-ending/control-character differences. Validate your own environment and packaging.
Exploitation status
- Public PoCs available since 9–14 July 2025.
- Actively exploited: CISA added CVE-2025-48384 to KEV on 25 Aug 2025. Agencies must remediate by 15 Sep 2025. Multiple outlets now report exploitation in the wild.
Technical detail (at a glance)
Root cause:
When Git reads config values, it strips trailing CR/LF. When it writes config entries, trailing \r may not be quoted, which gets lost on re-read. If a submodule path in .gitmodules ends with \r,
Git may use a different path when initializing, potentially outside the intended directory. If an attacker prepares a symlink into .git/hooks/ and places an executable hook, Git will execute that hook (e.g., post-checkout) after checkout → RCE.
Typical trigger:
git clone –recursive <attacker-repo> on Unix-like systems. Many READMEs encourage –recursive, making social engineering via public repos plausible.
Abuse primitives:
- Write malicious hook into <victim>/.git/hooks/ → code runs on common Git actions (commit/merge/checkout).
- Overwrite .git/config → change remotes, exfiltrate source, or persist stealthily.
Who’s most at risk
- Developers routinely cloning third-party/open-source repos.
- Build/CI systems that clone untrusted or community-supplied repos or run build jobs with developer-level credentials.
- GUI clients/IDEs that issue git clone –recursive under the hood until they bundle patched Git.
Confirming exposure
Endpoint/host: git –version and compare to patched lists below. (Also verify the embedded Git in IDEs/clients, not just /usr/bin/git.)
Fleet: check package manager baselines (e.g., updated Git 2.49.1+ in cloud images noted in release notes).
Immediate actions
Patch now
- Upgrade Git on macOS/Linux endpoints and CI images to v2.43.7 / v2.44.4 / v2.45.4 / v2.46.4 / v2.47.3 / v2.48.2 / v2.49.1 / v2.50.1 or newer. Rebuild golden images & containers.
- Ensure developer tools (IDEs, GUI clients) bundle a patched Git; otherwise force them to use the system Git path.
Temporary mitigations (until patch everywhere)
Do not git clone –recursive from untrusted repos; audit .gitmodules before cloning.
Consider setting a read-only or empty hooks path for untrusted work (e.g., core.hooksPath to a locked-down directory) and remove execute bits from hooks globally on developer boxes where feasible.
Stay Safe. Stay Secure.
OP Innovate Research Team
