gix-sec

Version	Released
`0.14.2` unknown	Jul 23, 2026
`0.14.1` unknown	May 26, 2026
`0.14.0` unknown	Apr 27, 2026
`0.13.3` unknown	Apr 24, 2026
`0.13.2` unknown 1 CVE	Mar 22, 2026
`0.13.1` unknown 1 CVE	Feb 10, 2026
`0.13.0` unknown 1 CVE	Jan 22, 2026
`0.12.2` unknown 1 CVE	Oct 23, 2025
`0.12.1` unknown 1 CVE	Oct 22, 2025
`0.12.0` unknown 1 CVE	Jul 15, 2025
`0.11.0` unknown 1 CVE	Apr 26, 2025
`0.10.13` unknown yanked 1 CVE	Apr 25, 2025
`0.10.12` unknown 1 CVE	Apr 04, 2025
`0.10.11` unknown 1 CVE	Jan 18, 2025
`0.10.10` unknown 1 CVE	Nov 24, 2024
`0.10.9` unknown 1 CVE	Oct 22, 2024
`0.10.8` unknown 1 CVE	Aug 22, 2024
`0.10.7` unknown 1 CVE	Jul 23, 2024
`0.10.6` unknown 1 CVE	Mar 14, 2024
`0.10.5` unknown 1 CVE	Feb 25, 2024
`0.10.4` unknown 1 CVE	Jan 20, 2024
`0.10.3` unknown 1 CVE	Dec 30, 2023
`0.10.2` unknown 1 CVE	Dec 29, 2023
`0.10.1` unknown 1 CVE	Dec 06, 2023
`0.10.0` unknown 1 CVE	Sep 08, 2023
`0.9.0` unknown 1 CVE	Aug 22, 2023
`0.8.4` unknown 1 CVE	Jul 22, 2023
`0.8.3` unknown 1 CVE	Jun 29, 2023
`0.8.2` unknown 1 CVE	Jun 22, 2023
`0.8.1` unknown 1 CVE	Jun 06, 2023
`0.8.0` unknown 1 CVE	Apr 27, 2023
`0.7.0` unknown 1 CVE	Apr 26, 2023
`0.6.2` unknown 1 CVE	Feb 17, 2023

0.14.2 unknown

Jul 23, 2026

0.14.1 unknown

May 26, 2026

0.14.0 unknown

Apr 27, 2026

0.13.3 unknown

Apr 24, 2026

0.13.2 unknown

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Mar 22, 2026

0.13.1 unknown

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Feb 10, 2026

0.13.0 unknown

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Jan 22, 2026

0.12.2 unknown

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Oct 23, 2025

0.12.1 unknown

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Oct 22, 2025

0.12.0 unknown

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Jul 15, 2025

0.11.0 unknown

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Apr 26, 2025

0.10.13 unknown yanked

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Apr 25, 2025

0.10.12 unknown

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Apr 04, 2025

0.10.11 unknown

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Jan 18, 2025

0.10.10 unknown

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Nov 24, 2024

0.10.9 unknown

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Oct 22, 2024

0.10.8 unknown

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Aug 22, 2024

0.10.7 unknown

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Jul 23, 2024

0.10.6 unknown

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Mar 14, 2024

0.10.5 unknown

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Feb 25, 2024

0.10.4 unknown

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Jan 20, 2024

0.10.3 unknown

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Dec 30, 2023

0.10.2 unknown

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Dec 29, 2023

0.10.1 unknown

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Dec 06, 2023

0.10.0 unknown

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Sep 08, 2023

0.9.0 unknown

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Aug 22, 2023

0.8.4 unknown

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Jul 22, 2023

0.8.3 unknown

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Jun 29, 2023

0.8.2 unknown

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Jun 22, 2023

0.8.1 unknown

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Jun 06, 2023

0.8.0 unknown

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Apr 27, 2023

0.7.0 unknown

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Apr 26, 2023

0.6.2 unknown

1 CVE

CVE-2025-24890 GHSA-7rhf-42qf-vrvc Sep 09, 2026

gix-sec safe.directory protections absent for elevated administrators

6.8 / 10

Medium

Local Low Low Required Unchanged High High Low

Summary

In a process run with full administrative rights on Windows, gix-sec wrongly treats all locations as trusted, leading to the execution of commands configured in repositories controlled by limited user accounts.

Details

In a similar way to Git, gitoxide tries to avoid operating in local repositories that it neither considers to be owned by the current user nor finds to match any value of safe.directory. This is because of the numerous commands that can be configured for a Git repository, to run as part of various actions, some of which even occur automatically due to the way custom shell prompts and text editors update their knowledge of repositories.

On Unix-like operating systems, every directory is considered to be owned by some user ID. On Windows, other identities can own a directory in the same sense that a user can, and directories created while operating with full administrative rights default to being owned by the Administrators group, not the specific user. Such administrators should be able to use what are, conceptually, their own repositories. So Git considers administrators (when operating this way) to own them.

Code in gix-sec intends to implement a similar check. But after finding that it is run with an administrative token, it needs to check if the directory is owned by the Administrators group, yet instead accidentally examines itself again, rather than the directory.

Specifically, in gix_sec::identity the implementation of is_path_owned_by_current_user for Windows finds the owner of the directory (folder_owner), finds the owner of the running thread or process (token_owner), checks cases of ownership not specific to administrators, then attempts to check the administrator-specific case with:

https://github.com/GitoxideLabs/gitoxide/blob/ffb73b5f69dbe86ff88f1c473af65f368a6bcbe5/gix-sec/src/identity.rs#L197-L207

The IsWellKnownSid call checks if the owner of the current thread or process is the Administrators group. By default, operations carried out when running as an administrator with UAC elevation--or using an administrative account for which UAC is turned off altogether--create not just files and directories with the Administrators group as the owner, but other securable objects as well, including processes and threads. So this check returns true. (Based on the comment, it may be that this was really meant to check if the directory is owned by an administrator. But nothing related to the directory appears in this check.)

The CheckTokenMembership call checks if the owner of the current thread or process is an identity enabled in the access token represented by the token handle of NULL, passed as 0. But a token handle of NULL represents the running thread. Consequently, if we have gotten this far--which happens when running with full administrative rights--in nearly all situations this will return true as well. (Based on the message, it may be that this was really meant to check if the user is an administrator. But nothing related to the Administrators group appears in this check.)

PoC

These examples use gix fetch for simplicity, but some other actions implemented in gitoxide are vulnerable, as well as any provided by applications that rely on the results of gix-sec checks.

Example 1: From inside a shared or user profile directory

On Windows, running as a limited user account, create a repository in a shared location like C:\Users\Public, or even within the limited user's user profile directory. Configure a fake (or, if preferred, real) remote and a value of core.sshCommand that runs an arbitrary payload. For example, in PowerShell:

git init unsafe-repo
cd unsafe-repo
git remote add origin ssh://localhost/repo.git
git config core.sshCommand 'calc.exe; ssh'

Switch from the limited account to an administrative account. Then:

If gitoxide is not installed, install it, such as with cargo install gitoxide.
Run PowerShell with UAC elevation, so that it and processes started in it have an unfiltered token. (If UAC is turned off for this account, then just run PowerShell normally.)
This example will not work if the GIT_SSH_COMMAND environment variable is set. It is not usually set, but if it may be, you can unset it in the current shell environment by running $env:GIT_SSH_COMMAND = $null.
cd to the limited user's repository as created above.
Run gix fetch. This runs the Windows calculator (the chosen payload).

Example 2: From anywhere

On Windows, even limited user accounts can create directories in the root of the system drive. As a limited user--and assuming the system drive is C:--initialize C:\ itself as a repository. Set up the repository to run the payload, either by editing C:\.git\config manually, or by running the git remote and git config commands from example 1 but passing -c safe.directory=.. The second approach is as follows:

cd C:\
git init
git -c safe.directory=. remote add origin ssh://localhost/repo.git
git -c safe.directory=. config core.sshCommand 'calc.exe; ssh'

(-c safe.directory=. keeps git from refusing to run the git remote and git config commands on the repository it has just created, whose .git directory is under its control but whose working tree is not.) The entire system drive is now a Git repository due to the presence of C:\.git. The limited user owns this .git directory and controls the configuration in it. Normally safe.directory protections keep this from being a problem. But they are ineffective for administrators running applications (such as the gix command) that use gix-sec to enforce those protections.

Switch from the limited account to an administrative account. Follow the instructions for the administrator from example 1, except do so from any directory anywhere on the C: drive that is not in its own repository. Unless GIT_CEILING_DIRECTORIES is set in such a way that keeps C:\ from being considered, running gix fetch again runs the Windows calculator. This happens even if the command is run from inside the administrator's own user profile directory.

Impact

A user is affected only when all of the following apply:

The operating system is Windows.
The user is a member of the Administrators group.
The program is run with the user's unfiltered token. This happens when UAC is enabled and the user runs the program with UAC elevation, as well as when UAC is disabled. (Running as an administrator but enabling UAC and running the program unelevated is sufficient to avoid this vulnerability.)
The program uses and relies on information from gix-sec about what directories to trust.
The program interacts with a repository owned by, and set up or controlled by, another user.

Then operations that would run code present in a repository's configuration or hooks when the repository is trusted will be performed in any repository. These operations often require user interaction. But this interaction may not seem to the user like it involves operations on a repository, if it is performed as part of a custom prompt for a shell, or by other software that integrates with repositories. It may also not seem like it involves operation on files controlled by another user, such as when the repository is the root of the system drive.

A malicious user with a limited account on the system may therefore be able to arrange for an administrator to run arbitrary code. However, this vulnerability does not affect cloning repositories or using repositories one has cloned, because cloning does not copy configuration and hooks into the local repository.

The specific attack of making the root of the system drive a repository resembles CVE-2022-24765. The workarounds presented there do not work around this vulnerability in full, but would prevent that kind of attack.

Fixed in


          0.13.3

References

Updated Sep 09, 2026 · Source: OSV.dev

Feb 17, 2023

Activity

Details