Git has released a new verson to address some security vulnerabilities, As reported, we are aware that GitHub is affected. But there is a need to upgrade your local installation of Git, especifially when you are using Git on Windows or on multi-user machines. All credit goes to to 俞晨东, and the fix was authored by Johannes Schindelin.
As stated in this article, this vulnerability affects multi-user machines, Git users might find themselves unexpectedly in a
Git worktree, e.g. when another user created a repository in
C:\.git, in a mounted network drive or in a scratch space. Merely having a Git-aware prompt that runs
git status (or
git diff) and navigate to a directory that is supposedly not a
Git worktree, or open such a directory in an editor or IDE such as VS Code or Atom, which will potentially run commands defined by that other user.
Since part of Git for Windows’ uninstaller is copied into the current user’s temporary directory and run in that place, it is important to ensure that there are no malicious
.dll file in that directory that might be loaded as part of loading the executable.
However, the default system settings for TMP and TEMP are to point to C:\Windows\Temp, a folder that is world-writable (for historical reasons), and the SYSTEM user account inherits those settings. This means that any authenticated user can place malicious .dll files that are loaded when Git for Windows’ uninstaller is run via the SYSTEM account.
How to Remediate this vulnerability
The most effective way to protect against this vulnerability is to upgrade to Git v2.35.2. This version changes Git’s behavior when looking for a top-level
.git directory to stop when its directory traversal changes ownership from the current user. (If you wish to make an exception to this behavior, you can use the new multi-valued
This will ensure the previous version of Git is uninstalled and have the new version “Git for Windows 2.35.2” is installed as shown below.
If you can’t upgrade immediately, there is a workaround to help reduce the following risk discussed above.
- Override SYSTEM’s
TMPenvironment variable to point to a directory exclusively under SYSTEM’s control before running the uninstaller
.dllfiles before running the uninstaller
- Running the uninstaller under an admin account rather than SYSTEM.