[PATCH] mingw: skip symlink type auto-detection for network share targets

[PATCH] mingw: skip symlink type auto-detection for network share targets

[Johannes Schindelin via GitGitGadget]

From: Johannes Schindelin <johannes.schindelin@gmx.de>

On Windows, symbolic links come in two flavors: file symlinks and
directory symlinks.  Since Git was born on Linux where this distinction
does not exist, Git for Windows has to auto-detect the type by looking
at the target.  When the target does not yet exist at symlink creation
time, Git for Windows creates a "phantom" file symlink and later, once
checkout is complete, calls `CreateFileW()` on the target to check
whether it is actually a directory.

If the symlink target is a UNC path (e.g. `\\attacker\share`), this
auto-detection triggers an SMB connection to the remote host.  Windows
performs NTLM authentication by default for such connections, which
means a crafted repository can exfiltrate the cloning user's NTLMv2 hash
to an attacker-controlled server without any user interaction beyond
`git clone -c core.symlinks=true <url>`.

There are ways to specify UNC paths that start with only a single
backslash (e.g. `\??\UNC\host\share`); All of them do start like that,
though, so let's use that as a tell-tale that we should skip the
auto-detection in `process_phantom_symlink()`. The symlink is then left
as a file symlink (the `mklink` default), and a warning is emitted
suggesting the user set the `symlink` gitattribute to `dir` if a
directory symlink is needed.  When the attribute is already set,
auto-detection is never invoked in the first place, so that code path is
unaffected.

This is the same class of vulnerability as CVE-2025-66413
(https://github.com/git-for-windows/git/security/advisories/GHSA-hv9c-4jm9-jh3x)
and follows the same general mitigation pattern that MinTTY adopted for
ANSI escape sequences referencing network share paths
(https://github.com/mintty/mintty/security/advisories/GHSA-jf4m-m6rv-p6c5).

Note that there are legitimate paths starting with a single backslash
that are _not_ network paths: drive-less absolute paths are interpreted
as relative to the current working directory's drive. In practice, these
are highly uncommon (and brittle, just one working directory change away
from breaking). In any case, the only consequence is now that the
symlink type of those has to be specified via Git attributes, is all.

Reported-by: Justin Lee <jessdhoctor@gmail.com>
Addresses: CVE-2026-32631
Assisted-by: Claude Opus 4.6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
    mingw: skip symlink type auto-detection for network share targets
    
    This was released as part of Git for Windows v2.53.0(3) already.

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2189%2Fdscho%2Fskip-symlink-detection-for-network-shares-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2189/dscho/skip-symlink-detection-for-network-shares-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/2189

 compat/mingw.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/compat/mingw.c b/compat/mingw.c
index 3eca3a7f2e..2b0d162d49 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -352,6 +352,29 @@ process_phantom_symlink(const wchar_t *wtarget, const wchar_t *wlink)
 	wchar_t relative[MAX_PATH];
 	const wchar_t *rel;
 
+	/*
+	 * Do not follow symlinks to network shares, to avoid NTLM credential
+	 * leak from crafted repositories (e.g. \\attacker-server\share).
+	 * Since paths come in all kind of enterprising shapes and forms (in
+	 * addition to the canonical `\\host\share` form, there's also
+	 * `\??\UNC\host\share`, `\GLOBAL??\UNC\host\share` and also
+	 * `\Device\Mup\host\share`, just to name a few), we simply avoid
+	 * following every symlink target that starts with a slash.
+	 *
+	 * This also catches drive-less absolute paths, of course. These are
+	 * uncommon in practice (and also fragile because they are relative to
+	 * the current working directory's drive). The only "harm" this does
+	 * is that it now requires users to specify via the Git attributes if
+	 * they have such an uncommon symbolic link and need it to be a
+	 * directory type link.
+	 */
+	if (is_wdir_sep(wtarget[0])) {
+		warning("created file symlink '%ls' pointing to '%ls';\n"
+			"set the `symlink` gitattribute to `dir` if a "
+			"directory symlink is required", wlink, wtarget);
+		return PHANTOM_SYMLINK_DONE;
+	}
+
 	/* check that wlink is still a file symlink */
 	if ((GetFileAttributesW(wlink)
 			& (FILE_ATTRIBUTE_REPARSE_POINT | FILE_ATTRIBUTE_DIRECTORY))

base-commit: 13c7afec212fc97ce257d15601659314c6673d6c
-- 
gitgitgadget

Re: [PATCH] mingw: skip symlink type auto-detection for network share targets

[Junio C Hamano]

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> On Windows, symbolic links come in two flavors: file symlinks and
> directory symlinks.  Since Git was born on Linux where this distinction
> does not exist, Git for Windows has to auto-detect the type by looking
> at the target.  When the target does not yet exist at symlink creation
> time, Git for Windows creates a "phantom" file symlink and later, once
> checkout is complete, calls `CreateFileW()` on the target to check
> whether it is actually a directory.
> ...
> Note that there are legitimate paths starting with a single backslash
> that are _not_ network paths: drive-less absolute paths are interpreted
> as relative to the current working directory's drive. In practice, these
> are highly uncommon (and brittle, just one working directory change away
> from breaking). In any case, the only consequence is now that the
> symlink type of those has to be specified via Git attributes, is all.

Thanks, will queue.