CVE-2025-48384

What it actually does

This vulnerability is an input-validation and path-confusion flaw in Git submodule handling. Git normalizes configuration values by stripping trailing CRLF when reading config, but when writing config entries it can fail to preserve a trailing carriage return in a submodule path. A repository can therefore define a submodule path that differs between write-time and read-time interpretation. During submodule initialization or checkout, Git may resolve the submodule into an unintended location. If the repository also contains a symlink that redirects the altered path into the submodule hooks directory, and the submodule includes an executable post-checkout hook, Git may execute attacker-controlled hook code as part of normal repository operations. The practical impact is local code execution in the context of the user or automation account running Git commands against a malicious repository.

Why it matters to the business

An attacker can turn a seemingly routine clone or submodule update into code execution on a developer workstation, build runner, CI worker, packaging system, or automation host. This can lead to theft of source code, credentials, signing keys, cloud tokens, package-publishing credentials, or insertion of malicious code into downstream software artifacts. Because this issue is listed in CISA KEV, has active in-the-wild exploitation, and has a remediation due date of 2025-09-15 for covered organizations, remediation should be treated as urgent even though the EPSS score is relatively low. The risk is highest for organizations that clone third-party repositories, build untrusted code, use Git submodules, or run automated dependency and packaging workflows.

How an attack unfolds

An attacker prepares a malicious Git repository containing a specially crafted submodule path with a trailing carriage return. The repository is structured so that Git records and later reads the submodule path differently because the trailing carriage return is lost during configuration processing. The attacker also places or induces a symlink so the normalized path resolves into the submodule's hooks directory. Inside that directory, the attacker provides an executable post-checkout hook. When a victim clones the repository and initializes or updates submodules, Git checks out the submodule into the attacker-influenced location and may execute the post-checkout hook automatically. The payload then runs with the privileges of the Git user or automation process, which can be a developer shell, CI job, package build container, or release pipeline. Public reporting tracks this as an actively exploited Git link-following vulnerability; defenders should assume malicious repositories may already be circulating.

How to fix it

Upgrade Git and Git-for-Windows to fixed releases immediately. The upstream fixed Git versions are v2.43.7, v2.44.4, v2.45.4, v2.46.4, v2.47.3, v2.48.2, v2.49.1, and v2.50.1 or later. For package-specific remediations provided in the input, upgrade helm-push for Chainguard to 0.10.4-r30 or later and helm-push for Wolfi to 0.10.4-r30 or later. Source-based consumers should include upstream Git commit 7a1903ad46b5cc7524c0734a5034dccaec07209b or later; Git-for-Windows consumers should include commit 4d32d83913170b86f9753fca10e75cdb2223d1cc or later. Prioritize patching developer workstations, CI/CD runners, build agents, release engineering systems, package builders, source mirrors, and any automation that clones external repositories or initializes submodules. Where immediate patching is not possible, avoid cloning untrusted repositories, disable or restrict recursive submodule initialization for untrusted code, run Git operations in isolated disposable sandboxes without secrets, mount workspaces with limited privileges, and prevent execution of repository-supplied hooks in automated workflows where feasible.

How to confirm the fix worked

Confirm all Git installations report a fixed version using `git --version` and verify the package manager, container image, developer tooling bundle, IDE-bundled Git, and CI runner images are not carrying older embedded Git binaries. Test representative build and clone workflows after upgrade, especially repositories using submodules. Review software bills of materials and base images for vulnerable Git or Git-for-Windows versions. For fixed package validation, confirm helm-push packages are at 0.10.4-r30 or later where applicable. To identify exposure, inventory systems that run `git clone --recurse-submodules`, `git submodule init`, `git submodule update`, or automated dependency fetches from third-party repositories. Inspect suspicious repositories for `.gitmodules` entries with carriage-return characters in submodule paths and for symlinks that point toward `.git/modules`, `hooks`, or submodule hook directories.

Typical attack path

1. Attacker creates or compromises a Git repository that uses submodules.
2. Attacker defines a submodule path containing a trailing carriage return so Git stores and later interprets the path inconsistently.
3. Attacker adds a symlink that causes the normalized submodule path to resolve into a Git hooks directory.
4. Attacker places an executable post-checkout hook containing the payload in the submodule content.
5. Victim clones the repository or runs submodule initialization/update commands against it.
6. Git processes the malformed submodule path, follows the attacker-controlled path redirection, and checks out content into the unintended location.
7. Git executes the attacker-controlled post-checkout hook during checkout.
8. Payload runs under the account executing Git and may steal credentials, modify source, persist in build scripts, or stage additional tooling.

How to detect it

Investigate whether Git operations against untrusted or recently added repositories executed unexpected hooks. Useful telemetry includes endpoint process creation logs, EDR events, shell history, CI/CD job logs, Git command logs, package build logs, file integrity monitoring, and repository workspace artifacts. Look for Git commands such as recursive clone or submodule update followed immediately by unusual child processes, including shells, scripting runtimes, download tools, credential-access commands, or network beacons. Inspect suspicious repositories and build workspaces for `.gitmodules` files containing literal carriage-return characters in submodule path values; these may appear as `^M`, `\r`, or abnormal line endings depending on tooling. Examine `.git/modules/*/hooks/` and submodule hook directories for executable `post-checkout` files. Also look for symlinks in repository worktrees that resolve into `.git/modules`, `.git/hooks`, or submodule hook directories. If suspicious hook execution is identified, preserve the repository, `.git` metadata, CI job workspace, process tree, command-line arguments, environment variables, and outbound network connection records, then rotate any credentials exposed to that execution context.

• .gitmodules
• post-checkout
• hooks/post-checkout
• .git/modules/
• /.git/modules/
• \r
• ^M
• git clone --recurse-submodules
• git submodule init
• git submodule update
• git submodule update --init
• git submodule update --init --recursive
• path = *^M
• .git/modules/*/hooks/post-checkout
• .git/hooks/post-checkout
• core.worktree

What your security team should do

• Treat this as urgent because it is in CISA KEV and is reported as actively exploited; complete remediation no later than the 2025-09-15 KEV deadline where applicable.
• Patch Git, Git-for-Windows, container images, CI runner images, developer workstation packages, IDE-bundled Git, and build toolchains to fixed versions.
• Temporarily block or sandbox cloning of untrusted repositories with submodules until patch coverage is verified.
• Hunt for recent clones or builds of unknown repositories that used recursive submodule initialization or submodule update commands.
• Search repositories and build workspaces for `.gitmodules` entries containing carriage-return characters and for executable `post-checkout` hooks in submodule hook paths.
• Remove secrets from Git clone/build environments where possible and rotate credentials if suspicious repository activity or hook execution is found.
• Add CI policy controls that prevent untrusted code from running with release, signing, package-publishing, or cloud-administration credentials.
• Monitor endpoint and CI telemetry for unusual child processes spawned by Git, shell interpreters, or hook scripts during checkout operations.