CVE-2026-109351 in Gix-Pack
Summary
by MITRE • 10/12/2026
Gitoxide gix-pack before 0.75.0 contains an uncontrolled memory allocation vulnerability that allows remote attackers to abort the process by supplying a huge pack-header object count. Malicious remotes can serve a 12-byte pack header claiming 0xFFFFFFFF objects, forcing Tree::with_capacity to reserve hundreds of gigabytes and crash clone or fetch operations.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified in Gitoxide versions prior to 0.75.0 represents a critical uncontrolled memory allocation flaw within the gix-pack component, which is responsible for handling Git pack files during repository cloning and fetching operations. This security issue stems from an insufficient validation of input data received from remote repositories, specifically concerning the object count field contained in the pack header. When a client initiates a clone or fetch operation against a maliciously configured remote server, it receives a standard 12-byte pack header that claims to contain an excessively large number of objects, specifically approaching the maximum value for a signed integer at 0xFFFFFFFF. This magnitude is orders of magnitude larger than any legitimate Git repository would ever contain and serves as a clear indicator of malformed or malicious input data intended to exploit resource management weaknesses in the parsing logic.
The technical core of this vulnerability lies in how the application processes the object count before allocating memory for subsequent operations. Upon receiving the pack header, the software attempts to pre-allocate memory buffers required to store the tree structures associated with the claimed objects by invoking a function such as Tree::with_capacity. Because the input value is not validated against realistic bounds or sanity-checked prior to allocation, the system interprets the massive integer literally and attempts to reserve hundreds of gigabytes of contiguous virtual address space. This action triggers an uncontrolled memory allocation event that exceeds available physical RAM and swap space, causing the operating system's out-of-memory killer to terminate the process abruptly. Consequently, this results in a denial of service condition where legitimate users attempting to interact with the repository experience immediate crashes during critical version control operations like cloning or fetching updates.
From an operational perspective, this vulnerability allows remote attackers to disrupt availability without requiring authentication or any form of user interaction beyond initiating a standard git clone or fetch command against a compromised or maliciously hosted Git server. The impact is strictly limited to denial of service as the attacker cannot execute arbitrary code through this specific vector; however, it effectively neutralizes access to the targeted repository and can be used in distributed attacks if multiple repositories are similarly configured. This flaw highlights the risks associated with trusting unverified metadata from remote sources without rigorous boundary checks, a common pitfall in network-facing software that processes binary protocols like Git pack files.
To mitigate this vulnerability, organizations must upgrade their gitoxide dependencies to version 0.75.0 or later where the issue has been resolved through improved input validation and resource limits. In environments where immediate patching is not feasible, defensive measures should include implementing network-level filtering to inspect HTTP responses for abnormally large pack headers before they reach the client application. Additionally, developers integrating gitoxide into custom tools should ensure that their build configurations enforce strict memory usage policies or utilize containerization with limited resources to contain potential crashes. Adhering to secure coding standards such as CWE-789 which addresses uncontrolled memory allocation is essential for preventing similar issues in future development cycles, ensuring that all external inputs are validated against expected ranges before being used for resource-intensive operations.