Description

gitoxide is an implementation of git written in Rust. Prior to 0.13.3, the gix-sec crate on Windows incorrectly treats repositories controlled by another user as trusted when an administrator runs a dependent program with an unfiltered elevated token. In gix-sec/src/identity.rs, gix_sec::identity::is_path_owned_by_current_user obtains folder_owner and token_owner, but its administrator-specific IsWellKnownSid and CheckTokenMembership checks examine the running token rather than confirming the directory owner. This bypasses safe.directory-style protection for repositories owned and configured by a limited user, allowing repository configuration or hooks to execute commands with the administrator's privileges when an affected operation is performed. Exploitation requires Windows, an elevated administrator, a program that relies on gix-sec trust results, and interaction with a repository controlled by another user. An unelevated UAC process is not affected, and cloning is not affected because repository configuration and hooks are not copied. This issue is fixed in version 0.13.3.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.8",
  "pubDate": "2026-09-14T16:17:05.117Z",
  "pubdate": "2026-09-14T16:17:05.117Z",
  "executiveSummary": "The gitoxide library, specifically the gix-sec crate, contains a critical security flaw involving the improper validation of directory ownership on Windows systems.\nThis vulnerability allows an attacker to gain elevated privileges when an administrator executes a program linked against the affected library version.\nThe flaw stems from the failure of gix_sec::identity::is_path_owned_by_current_user to correctly verify the ownership of a repository directory before establishing trust.\nBy performing operations on a malicious repository, an attacker can coerce an elevated process into executing arbitrary commands defined within the repository's configuration or hooks.\nThe vulnerability is restricted to Windows environments where an elevated administrator interacts with a repository owned by a lower-privileged user.\nThis creates a significant risk of local privilege escalation, as the malicious code runs with the elevated privileges of the administrator process.\nThe issue is resolved in version 0.13.3 of the gix-sec crate. Systems should be audited for dependence on older, vulnerable versions of this crate to prevent unauthorized command execution.",
  "technicalDetails": "The root cause of the vulnerability resides in gix-sec/src/identity.rs within the function gix_sec::identity::is_path_owned_by_current_user. On Windows, the implementation fails to correctly validate whether a target directory is owned by the current user when the process is running under an elevated administrator token.\nWhile the function attempts to retrieve both the folder owner and the token owner, the subsequent verification logic is flawed. Instead of validating the directory's actual ownership against the user's security identifier (SID), the code relies on IsWellKnownSid and CheckTokenMembership checks applied to the current security token. This logic incorrectly assumes that the identity of the process token is sufficient evidence to trust a directory, bypassing the critical security check meant to ensure that the repository is owned by the current user.\nThis oversight breaks the trust boundary for safe.directory-style protections. In a typical attack flow, an attacker creates a malicious repository containing custom configuration settings or executable hooks. The attacker then encourages an administrator, who is running an application utilizing the vulnerable version of gix-sec, to perform operations within this repository. Because the vulnerable code incorrectly flags the directory as 'trusted' (despite the directory being owned by the attacker), the application proceeds to load and execute the untrusted repository configuration or hooks.\nSince the host process is running with an elevated administrator token, the hooks executed by the library inherit these elevated privileges. This results in arbitrary code execution with administrator rights. The exploitation requires a specific configuration: a Windows environment, an elevated process (with an unfiltered token), and an application that relies on the gix-sec trust determination to execute repository-level actions. Cloning operations are naturally exempt from this risk as they do not invoke existing hooks or configurations from the source, but subsequent operations by an elevated user on a pre-existing, attacker-controlled repository are susceptible.\nThis flaw is present in all versions of the gix-sec crate prior to 0.13.3. Post-exploitation, the attacker achieves code execution within the context of the elevated process, enabling full system compromise depending on the capabilities of the host application."
}