Merge tag 'v2.53.0.windows.3' into merge-v2.53.0.windows.3-into-vfs-2.53.0

Git for Windows v2.53.0(3)

Changes since Git for Windows v2.53.0(2) (March 10th 2026):

This is a security fix release, addressing CVE-2026-32631.

  * CVE-2026-32631, Git for Windows: When a user clones a repository
    containing symbolic links pointing to network drives, Git follows
    those symlinks during checkout, causing Windows to transparently
    perform NTLM authentication and disclose the user's NTLMv2 hash to
    an attacker-controlled server. Since NTLM hashing is weak, the
    captured hash can potentially be brute-forced to recover the user's
    credentials. This is addressed by preventing git clone from
    following symbolic links that point to network drives during
    checkout.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Author: dscho

.github/workflows/main.yml

@@ -423,7 +423,9 @@ jobs:
       CI_JOB_IMAGE: ${{matrix.vector.image}}
       CUSTOM_PATH: /custom
     runs-on: ubuntu-latest
-    container: ${{matrix.vector.image}}
+    container:
+      image: ${{ matrix.vector.image }}
+      options: ${{ github.repository_visibility == 'private' && '--pids-limit 16384 --ulimit nproc=16384:16384 --ulimit nofile=32768:32768' || '' }}
     steps:
     - name: prepare libc6 for actions
       if: matrix.vector.jobname == 'linux32'

compat/mingw.c

@@ -385,6 +385,29 @@ process_phantom_symlink(const wchar_t *wtarget, const wchar_t *wlink)
 	wchar_t relative[MAX_LONG_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))