Description

gitoxide (Rust crates gix <= 0.72.0 and gix-validate <= 0.10.0) contains a path traversal vulnerability. The submodule name validation function in gix-validate only checks the first occurrence of '..' via name.find(b".."), allowing crafted names such as 'a..b/../../../.git/' to bypass the check; additionally this validation is never invoked in production code paths. Combined with a trust inheritance flaw in Submodule::open(), where the parent repository's git_dir_trust (Trust::Full) is cloned and the ownership verification is skipped, an attacker can craft a malicious .gitmodules file so that a victim tool built on gitoxide reads arbitrary git repository configuration (including embedded credentials) with full trust, bypassing safe-directory protections. Fixed in gix 0.82.0 and gix-validate 0.11.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-28T12:16:38.027Z",
  "pubdate": "2026-08-28T12:16:38.027Z",
  "executiveSummary": "The gitoxide library (gix and gix-validate crates) is susceptible to a critical path traversal and trust inheritance vulnerability. The flaw stems from insufficient validation of submodule names in gix-validate and an improper security context propagation in Submodule::open().\nAn attacker can exploit this by crafting a malicious .gitmodules file, causing a host application to treat arbitrary file system paths as legitimate git repositories. Because the parent repository's 'Trust::Full' status is inherited without re-verifying ownership, the vulnerability bypasses Git's 'safe-directory' protections.\nThis allows for unauthorized read access to sensitive configurations, including embedded credentials stored within git repository structures. The impact is significant for tools utilizing gitoxide to process untrusted repositories, as the vulnerability circumvents existing sandbox mechanisms. Exploitation requires the victim to process a maliciously crafted git repository containing the crafted submodule configuration.\nThe vulnerability affects gix versions <= 0.72.0 and gix-validate versions <= 0.10.0. Remediation requires updating to the patched versions where input sanitization is strictly enforced and trust inheritance is properly scoped.",
  "technicalDetails": "The root cause is twofold: an inadequate input sanitization mechanism in the submodule validation logic and an insecure trust model in the submodule initialization process.\nFirst, the validation routine for submodule names within gix-validate uses a non-recursive search (name.find(b\"..\")). By utilizing crafted names such as 'a..b/../../../.git/', an attacker can force the parser to interpret the path as a traversal sequence that escapes the intended subdirectory boundaries. Furthermore, this validation check is documented as not being invoked within production-ready code paths, rendering the existing (albeit weak) safeguard useless.\nSecond, the Submodule::open() function implementation suffers from a trust inheritance flaw. When a parent repository is opened with 'Trust::Full', this trust status is automatically inherited by the submodule being opened. The library fails to perform an independent verification of the submodule's ownership or security context at the point of initialization.\nThe attack flow proceeds as follows: 1) An attacker provides a repository containing a malicious .gitmodules configuration file. 2) The victim tool calls Submodule::open() on this repository. 3) Due to the insufficient path validation, the system resolves the submodule path to an arbitrary location on the file system, potentially pointing to sensitive directories. 4) The application, having inherited the 'Trust::Full' state from the parent, fails to validate ownership of the newly resolved path, thus bypassing 'safe-directory' checks that would normally block access to untrusted repositories. 5) The application proceeds to parse the target directory as a git repository, allowing the attacker to exfiltrate configuration details, including credentials or other sensitive files accessed by the library with elevated trust.\nThis vulnerability is particularly dangerous because it leverages the library's own internal trust mechanisms against itself, effectively neutralizing security hardening features like safe-directory protections implemented by the underlying git infrastructure."
}