CVE-2019-1353 in Git
Summary
by MITRE
An issue was found in Git before v2.24.1, v2.23.1, v2.22.2, v2.21.1, v2.20.2, v2.19.3, v2.18.2, v2.17.3, v2.16.6, v2.15.4, and v2.14.6. When running Git in the Windows Subsystem for Linux (also known as "WSL") while accessing a working directory on a regular Windows drive, none of the NTFS protections were active.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 04/17/2025
This vulnerability in Git affects multiple versions prior to specific patch releases including v2.24.1 through v2.14.6 and represents a critical security flaw when Git operates within the Windows Subsystem for Linux environment. The issue stems from how Git handles file system permissions when accessing working directories stored on Windows drives through WSL. When Git runs in WSL context while interacting with files located on standard Windows NTFS drives, the system fails to enforce NTFS security protections that would normally restrict access based on user permissions and access control lists. This creates a scenario where Git operations can bypass the normal file system security mechanisms that protect against unauthorized access to files and directories, effectively rendering the NTFS permission model ineffective within the WSL environment.
The technical flaw manifests in Git's file system interaction layer where it does not properly translate or respect the security attributes that NTFS provides when files are accessed through the WSL subsystem. This occurs because WSL maintains a translation layer between the Linux file system interface and the Windows NTFS file system, but Git's implementation fails to correctly handle the security context when performing operations on Windows drives. The vulnerability specifically impacts scenarios where users have Git repositories located on Windows drives such as C: or other mounted Windows volumes, while executing Git commands within the WSL environment. This creates a potential privilege escalation vector where a malicious actor could access files that should be restricted by NTFS permissions, or where legitimate users might inadvertently expose sensitive data through improper access control.
The operational impact of this vulnerability extends beyond simple permission bypass to potentially expose sensitive data and create security risks for organizations using WSL with Git. When Git operations occur on Windows drives within WSL, any file access patterns that should be restricted by NTFS permissions become accessible to all processes running within the WSL environment. This affects not only repository files but also any other sensitive data stored on Windows drives that might be accessed through Git operations. The vulnerability can be exploited by attackers who gain access to a WSL environment to potentially read files that should be restricted, or by malicious code running within WSL to access Windows drive data that it should not have access to. This creates a significant risk for organizations that store sensitive data on Windows drives and use Git within WSL for development work, as the security boundary between Linux and Windows file systems becomes effectively meaningless.
Organizations should immediately upgrade to Git versions that include the security patches for this vulnerability, specifically targeting versions v2.24.1, v2.23.1, v2.22.2, v2.21.1, v2.20.2, v2.19.3, v2.18.2, v2.17.3, v2.16.6, v2.15.4, and v2.14.6 or later. The mitigation strategy should include implementing additional access controls and monitoring for unauthorized access to Windows drives when using WSL, as well as ensuring that developers are aware of the security implications of storing sensitive data on Windows drives while using Git in WSL environments. Security teams should also consider implementing network segmentation and access controls to limit the potential impact if this vulnerability is exploited, and establish policies that prevent the use of WSL with Git for repositories containing sensitive data stored on Windows drives. This vulnerability aligns with CWE-284 Access Control Issues and can be mapped to ATT&CK technique T1078 Valid Accounts for privilege escalation scenarios, as it allows unauthorized access to files through the bypass of normal access controls.