Disable Git daemon.uploadArch to Mitigate CVE-2022-41903 on Windows

What the Git daemon.uploadArch Worklet does

This Automox Worklet™ sets daemon.uploadArch to false in the system-level Git configuration on Windows endpoints. CVE-2022-41903 is an integer overflow in the export-subst mechanism of git archive that can lead to arbitrary heap writes and possible code execution. The Git security release that covers GHSA-c738-c5qq-xg89 and GHSA-475x-2q3q-hvwq publishes daemon.uploadArch=false as the workaround for CVE-2022-41903. That setting stops git daemon from serving git archive --remote requests. Local git archive runs on the endpoint are unaffected.

The scope is CVE-2022-41903 only. Tenable plugin 184470, the check that reports this issue, also reports CVE-2022-23521, an integer overflow in .gitattributes parsing. Git publishes no configuration workaround for that CVE. Upgrading Git for Windows to 2.30.7, 2.31.6, 2.32.5, 2.33.6, 2.34.6, 2.35.6, 2.36.4, 2.37.5, 2.38.3, 2.39.1, or later resolves CVE-2022-23521. Because the plugin is a version check, a scanned host will likely stay flagged until Git itself is upgraded.

Before it reads or writes anything, the Worklet finds git.exe. It opens the 64-bit registry view and walks both SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall and the WOW6432Node equivalent, matching DisplayName values anchored to ^Git\b, so GitHub Desktop, GitKraken, and TortoiseGit are skipped. It then tests InstallLocation\bin\git.exe followed by InstallLocation\cmd\git.exe, and falls back to the Git paths under Program Files and Program Files (x86). An endpoint with no registered Git install exits 0 as not applicable.

Why disable git daemon archive uploads

git daemon serves repositories over the unauthenticated git:// protocol. When upload-archive is enabled, any client that reaches the port can make the daemon run git archive against a hosted repository. A crafted export-subst payload inside that repository is what CVE-2022-41903 abuses. A heap write in that code path on a build server or an internal mirror hands an attacker execution in the context of the daemon account.

Upgrading Git for Windows across a fleet takes a change window, and build agents, developer laptops, and self-hosted mirrors rarely move on the same schedule. Setting daemon.uploadArch to false at the system level closes the remote archive path today, and it costs nothing on the many hosts that never run git daemon at all.

Applying the setting by hand means finding every Git install, running git config as an account that can write the system config, and recording what the value was before you changed it. This Worklet does all three, saves the prior state so you can reverse the change, and returns a clean compliant or non-compliant signal you can track across the fleet.

How the daemon.uploadArch mitigation works

1. Evaluation phase: Locates git.exe through the uninstall registry keys and the Program Files fallbacks, then runs git config --system --get daemon.uploadArch with a bounded 60-second wait. Exit code 0 with a value of false reports the endpoint compliant. Any other value, a key that is not set (exit code 1), or a system config that is not available (exit code 5) reports non-compliant, because the advisory calls for the setting to be present and explicit. The Worklet terminates a git call that runs past 60 seconds and reports it non-compliant. An endpoint with no Git install exits 0 as not applicable.

2. Remediation phase: Repeats the discovery, re-reads the current value, and exits without changing anything when it is already false. Otherwise it writes the prior value to C:\Program Files (x86)\Automox\WorkletCache\edd770f3-05bb-551b-b0be-13f8ccb47eb0\daemon_uploadArch_prior.txt, using the sentinel __NOT_SET__ when no value existed. It then runs git config --system daemon.uploadArch false and re-reads the key to confirm the write. Setting the dryrun switch logs every step and exits without changing state. Setting the rollback switch restores the backed-up value, or unsets the key when the sentinel is present.

Git daemon.uploadArch mitigation requirements

• Windows 10 or Windows 11 x64, or Windows Server 2016 and later, with PowerShell 5.1 or newer

• The Automox agent running as SYSTEM, since the Worklet reads HKLM and writes the system-level Git configuration

• Git for Windows registered under the uninstall registry keys, or installed in the default Program Files location: portable and per-user Git installations that the registry does not list will not be found

• Write access to the system Git config file, normally C:\Program Files\Git\etc\gitconfig; a system config that git cannot locate returns exit code 5 on the read

• A plan for the permanent fix, since only a Git for Windows upgrade to 2.30.7, 2.31.6, 2.32.5, 2.33.6, 2.34.6, 2.35.6, 2.36.4, 2.37.5, 2.38.3, 2.39.1, or later resolves CVE-2022-23521

• An optional rollback path: the backup file under the Automox WorkletCache directory holds the prior value, and the rollback switch restores or unsets it

Expected Git configuration after the mitigation

On an endpoint with Git installed, git config --system --get daemon.uploadArch returns false, and the Activity Log records the git.exe path that was found, the prior value that was backed up, the write, and the post-verify read. Re-running evaluation returns compliant. Absent a per-repository override, git daemon on that host no longer serves git archive --remote requests. Local git archive commands keep working as before.

Endpoints without Git report compliant with a not-applicable note in the log. Read a compliant result as the CVE-2022-41903 workaround being in place, not as CVE-2022-23521 being closed. Your scanner reads the Git version, so Tenable plugin 184470 will likely keep firing until you upgrade Git for Windows to a fixed release. Track those hosts as patch work, and use the rollback switch if the setting interrupts an internal workflow that depends on remote archives.