gitoxide

Summary

attachments: pocs.zip

Submodule names coming from .gitmodules are exposed as unvalidated names and are later reused to derive the submodule git directory as:

<superproject common_dir>/modules/<submodule name>

Because the submodule name is joined directly as a filesystem path component, a name such as ../../../escaped-target.git escapes .git/modules after normalization. The current implementation then uses that escaped path in both state() and open().

The updated PoC demonstrates the real sink, not just string construction:

• state() reports repository_exists=true for the traversed path;
• open() returns a repository whose normalized common_dir() matches the attacker-chosen repository outside .git/modules.

Root cause analysis

The relevant flow is:

1. gix-submodule/src/access.rs exposes unvalidated submodule names from configuration.
2. gix/src/submodule/mod.rs derives the git directory by doing common_dir().join("modules").join(name) with no confinement check.
3. gix/src/submodule/mod.rs uses that derived path during state resolution and repository opening.

There is no normalization-and-confinement step between “submodule name from configuration” and “filesystem path used for repository existence checks / open.” As a result, traversal segments in the submodule name directly influence which repository path is inspected and opened.

Reproduce steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F002.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F002/result.txt.

Key outputs are:

• submodule_name=../../../escaped-target.git
• derived_git_dir_raw=.../.git/modules/../../../escaped-target.git
• derived_git_dir_normalized=.../artifacts/escaped-target.git
• escaped_target=.../artifacts/escaped-target.git
• repository_exists=true
• submodule_opened=true
• opened_common_dir_normalized=.../artifacts/escaped-target.git
• normalized_git_dir_matches_target=true
• opened_common_dir_matches_target=true
• target_outside_modules_root=true

These outputs show that gitoxide is not only constructing a traversable path string. It is actually using the escaped path for repository existence checks and for opening a repository object.

Impact

Confirmed impact:

• a malicious submodule name can redirect submodule state inspection away from .git/modules/<name> to an attacker-chosen repository path outside .git/modules;
• Submodule::state() can report repository existence for the wrong repository;
• Submodule::open() can return a repository object backed by that attacker-chosen path.

This is best described as a path-traversal / repository-confusion issue in submodule repository resolution.

This report does not claim command execution from this behavior alone. The demonstrated impact is repository redirection: callers that enumerate, inspect, or operate on submodules can be steered into using the wrong repository.

Recommended fix

Two complementary fixes are advisable:

1. do not reuse raw submodule names as filesystem path fragments;
   • either use a validated/sanitized name for filesystem derivation,
   • or derive the storage path from a safe identifier instead of the user-controlled name;
2. add an explicit confinement check after path derivation;
   • normalize or canonicalize the candidate path,
   • verify that the result stays under <common_dir>/modules,
   • reject names that contain traversal segments, path separators, or any representation that can escape the modules root.

In short, submodule names may remain opaque configuration identifiers, but they should not be treated as trusted filesystem subpaths.

Summary

attachments: pocs.zip

When Repository::submodules() loads submodule metadata, it prefers the worktree .gitmodules file if that path exists. In the current implementation, the path is read with std::fs::read(), which follows symlinks. As a result, a repository can present a symlinked .gitmodules that points outside the repository, and gitoxide will parse the out-of-repository bytes as submodule configuration.

This is a repository-boundary violation. A caller using the high-level submodule API can believe it is reading repository-local submodule metadata, while the bytes are actually coming from an arbitrary file outside the repository tree.

Root cause analysis

The relevant flow is:

1. gix/src/repository/location.rs derives the worktree .gitmodules path as workdir/.gitmodules.
2. gix/src/repository/submodule.rs reads that path with std::fs::read(&path) and immediately parses the bytes as a submodule configuration file.
3. Repository::submodules() exposes the parsed entries through the high-level API.

The issue is not in the parser. The issue is that the worktree path is treated as an ordinary file without checking whether it is a symlink, and without checking whether the canonicalized target remains inside the repository worktree.

Because std::fs::read() follows symlinks, a malicious repository can cause gitoxide to ingest bytes from an attacker-chosen location outside the repository. The resulting Submodule objects then expose name, path, and url values derived from that external file.

Reproduction steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F001.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F001/result.txt.

Important outputs include:

• gitmodules_symlink=.../victim-repo/.gitmodules
• symlink_target=.../outside/modules.conf
• parsed_name=symlinked
• parsed_path=deps/symlinked
• parsed_url=https://attacker.example/symlinked.git

These outputs show that gitoxide parsed the submodule configuration from the symlink target outside the repository, not from repository-local bytes.

Impact

Confirmed impact:

• out-of-repository bytes can be injected into the result of Repository::submodules();
• callers can be misled about submodule metadata such as name, path, and url;
• any downstream workflow that uses those values to decide clone, fetch, update, or policy behavior is operating on attacker-controlled data that did not actually originate from the repository tree.

This report does not claim direct command execution from this code path by itself. The demonstrated impact is metadata injection across the repository boundary.

Recommended fix

A safe fix is to stop silently following symlinks for the worktree .gitmodules path in this loading path.

Reasonable options include:

1. use symlink_metadata() / lstatstyle checks and reject symlinked .gitmodules when loading from the worktree;
2. canonicalize the target and verify that it still resides under the repository worktree before reading it;
3. for security-sensitive callers, prefer loading .gitmodules from the index or HEAD tree rather than following the worktree path.

At minimum, the worktree path should not silently follow symlinks to arbitrary external files.

Summary

attachments: pocs.zip

Submodule names coming from .gitmodules are exposed as unvalidated names and are later reused to derive the submodule git directory as:

<superproject common_dir>/modules/<submodule name>

Because the submodule name is joined directly as a filesystem path component, a name such as ../../../escaped-target.git escapes .git/modules after normalization. The current implementation then uses that escaped path in both state() and open().

The updated PoC demonstrates the real sink, not just string construction:

• state() reports repository_exists=true for the traversed path;
• open() returns a repository whose normalized common_dir() matches the attacker-chosen repository outside .git/modules.

Root cause analysis

The relevant flow is:

1. gix-submodule/src/access.rs exposes unvalidated submodule names from configuration.
2. gix/src/submodule/mod.rs derives the git directory by doing common_dir().join("modules").join(name) with no confinement check.
3. gix/src/submodule/mod.rs uses that derived path during state resolution and repository opening.

There is no normalization-and-confinement step between “submodule name from configuration” and “filesystem path used for repository existence checks / open.” As a result, traversal segments in the submodule name directly influence which repository path is inspected and opened.

Reproduce steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F002.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F002/result.txt.

Key outputs are:

• submodule_name=../../../escaped-target.git
• derived_git_dir_raw=.../.git/modules/../../../escaped-target.git
• derived_git_dir_normalized=.../artifacts/escaped-target.git
• escaped_target=.../artifacts/escaped-target.git
• repository_exists=true
• submodule_opened=true
• opened_common_dir_normalized=.../artifacts/escaped-target.git
• normalized_git_dir_matches_target=true
• opened_common_dir_matches_target=true
• target_outside_modules_root=true

These outputs show that gitoxide is not only constructing a traversable path string. It is actually using the escaped path for repository existence checks and for opening a repository object.

Impact

Confirmed impact:

• a malicious submodule name can redirect submodule state inspection away from .git/modules/<name> to an attacker-chosen repository path outside .git/modules;
• Submodule::state() can report repository existence for the wrong repository;
• Submodule::open() can return a repository object backed by that attacker-chosen path.

This is best described as a path-traversal / repository-confusion issue in submodule repository resolution.

This report does not claim command execution from this behavior alone. The demonstrated impact is repository redirection: callers that enumerate, inspect, or operate on submodules can be steered into using the wrong repository.

Recommended fix

Two complementary fixes are advisable:

1. do not reuse raw submodule names as filesystem path fragments;
   • either use a validated/sanitized name for filesystem derivation,
   • or derive the storage path from a safe identifier instead of the user-controlled name;
2. add an explicit confinement check after path derivation;
   • normalize or canonicalize the candidate path,
   • verify that the result stays under <common_dir>/modules,
   • reject names that contain traversal segments, path separators, or any representation that can escape the modules root.

In short, submodule names may remain opaque configuration identifiers, but they should not be treated as trusted filesystem subpaths.

Summary

attachments: pocs.zip

When Repository::submodules() loads submodule metadata, it prefers the worktree .gitmodules file if that path exists. In the current implementation, the path is read with std::fs::read(), which follows symlinks. As a result, a repository can present a symlinked .gitmodules that points outside the repository, and gitoxide will parse the out-of-repository bytes as submodule configuration.

This is a repository-boundary violation. A caller using the high-level submodule API can believe it is reading repository-local submodule metadata, while the bytes are actually coming from an arbitrary file outside the repository tree.

Root cause analysis

The relevant flow is:

1. gix/src/repository/location.rs derives the worktree .gitmodules path as workdir/.gitmodules.
2. gix/src/repository/submodule.rs reads that path with std::fs::read(&path) and immediately parses the bytes as a submodule configuration file.
3. Repository::submodules() exposes the parsed entries through the high-level API.

The issue is not in the parser. The issue is that the worktree path is treated as an ordinary file without checking whether it is a symlink, and without checking whether the canonicalized target remains inside the repository worktree.

Because std::fs::read() follows symlinks, a malicious repository can cause gitoxide to ingest bytes from an attacker-chosen location outside the repository. The resulting Submodule objects then expose name, path, and url values derived from that external file.

Reproduction steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F001.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F001/result.txt.

Important outputs include:

• gitmodules_symlink=.../victim-repo/.gitmodules
• symlink_target=.../outside/modules.conf
• parsed_name=symlinked
• parsed_path=deps/symlinked
• parsed_url=https://attacker.example/symlinked.git

These outputs show that gitoxide parsed the submodule configuration from the symlink target outside the repository, not from repository-local bytes.

Impact

Confirmed impact:

• out-of-repository bytes can be injected into the result of Repository::submodules();
• callers can be misled about submodule metadata such as name, path, and url;
• any downstream workflow that uses those values to decide clone, fetch, update, or policy behavior is operating on attacker-controlled data that did not actually originate from the repository tree.

This report does not claim direct command execution from this code path by itself. The demonstrated impact is metadata injection across the repository boundary.

Recommended fix

A safe fix is to stop silently following symlinks for the worktree .gitmodules path in this loading path.

Reasonable options include:

1. use symlink_metadata() / lstatstyle checks and reject symlinked .gitmodules when loading from the worktree;
2. canonicalize the target and verify that it still resides under the repository worktree before reading it;
3. for security-sensitive callers, prefer loading .gitmodules from the index or HEAD tree rather than following the worktree path.

At minimum, the worktree path should not silently follow symlinks to arbitrary external files.

Summary

attachments: pocs.zip

Submodule names coming from .gitmodules are exposed as unvalidated names and are later reused to derive the submodule git directory as:

<superproject common_dir>/modules/<submodule name>

Because the submodule name is joined directly as a filesystem path component, a name such as ../../../escaped-target.git escapes .git/modules after normalization. The current implementation then uses that escaped path in both state() and open().

The updated PoC demonstrates the real sink, not just string construction:

• state() reports repository_exists=true for the traversed path;
• open() returns a repository whose normalized common_dir() matches the attacker-chosen repository outside .git/modules.

Root cause analysis

The relevant flow is:

1. gix-submodule/src/access.rs exposes unvalidated submodule names from configuration.
2. gix/src/submodule/mod.rs derives the git directory by doing common_dir().join("modules").join(name) with no confinement check.
3. gix/src/submodule/mod.rs uses that derived path during state resolution and repository opening.

There is no normalization-and-confinement step between “submodule name from configuration” and “filesystem path used for repository existence checks / open.” As a result, traversal segments in the submodule name directly influence which repository path is inspected and opened.

Reproduce steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F002.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F002/result.txt.

Key outputs are:

• submodule_name=../../../escaped-target.git
• derived_git_dir_raw=.../.git/modules/../../../escaped-target.git
• derived_git_dir_normalized=.../artifacts/escaped-target.git
• escaped_target=.../artifacts/escaped-target.git
• repository_exists=true
• submodule_opened=true
• opened_common_dir_normalized=.../artifacts/escaped-target.git
• normalized_git_dir_matches_target=true
• opened_common_dir_matches_target=true
• target_outside_modules_root=true

These outputs show that gitoxide is not only constructing a traversable path string. It is actually using the escaped path for repository existence checks and for opening a repository object.

Impact

Confirmed impact:

• a malicious submodule name can redirect submodule state inspection away from .git/modules/<name> to an attacker-chosen repository path outside .git/modules;
• Submodule::state() can report repository existence for the wrong repository;
• Submodule::open() can return a repository object backed by that attacker-chosen path.

This is best described as a path-traversal / repository-confusion issue in submodule repository resolution.

This report does not claim command execution from this behavior alone. The demonstrated impact is repository redirection: callers that enumerate, inspect, or operate on submodules can be steered into using the wrong repository.

Recommended fix

Two complementary fixes are advisable:

1. do not reuse raw submodule names as filesystem path fragments;
   • either use a validated/sanitized name for filesystem derivation,
   • or derive the storage path from a safe identifier instead of the user-controlled name;
2. add an explicit confinement check after path derivation;
   • normalize or canonicalize the candidate path,
   • verify that the result stays under <common_dir>/modules,
   • reject names that contain traversal segments, path separators, or any representation that can escape the modules root.

In short, submodule names may remain opaque configuration identifiers, but they should not be treated as trusted filesystem subpaths.

Summary

attachments: pocs.zip

When Repository::submodules() loads submodule metadata, it prefers the worktree .gitmodules file if that path exists. In the current implementation, the path is read with std::fs::read(), which follows symlinks. As a result, a repository can present a symlinked .gitmodules that points outside the repository, and gitoxide will parse the out-of-repository bytes as submodule configuration.

This is a repository-boundary violation. A caller using the high-level submodule API can believe it is reading repository-local submodule metadata, while the bytes are actually coming from an arbitrary file outside the repository tree.

Root cause analysis

The relevant flow is:

1. gix/src/repository/location.rs derives the worktree .gitmodules path as workdir/.gitmodules.
2. gix/src/repository/submodule.rs reads that path with std::fs::read(&path) and immediately parses the bytes as a submodule configuration file.
3. Repository::submodules() exposes the parsed entries through the high-level API.

The issue is not in the parser. The issue is that the worktree path is treated as an ordinary file without checking whether it is a symlink, and without checking whether the canonicalized target remains inside the repository worktree.

Because std::fs::read() follows symlinks, a malicious repository can cause gitoxide to ingest bytes from an attacker-chosen location outside the repository. The resulting Submodule objects then expose name, path, and url values derived from that external file.

Reproduction steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F001.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F001/result.txt.

Important outputs include:

• gitmodules_symlink=.../victim-repo/.gitmodules
• symlink_target=.../outside/modules.conf
• parsed_name=symlinked
• parsed_path=deps/symlinked
• parsed_url=https://attacker.example/symlinked.git

These outputs show that gitoxide parsed the submodule configuration from the symlink target outside the repository, not from repository-local bytes.

Impact

Confirmed impact:

• out-of-repository bytes can be injected into the result of Repository::submodules();
• callers can be misled about submodule metadata such as name, path, and url;
• any downstream workflow that uses those values to decide clone, fetch, update, or policy behavior is operating on attacker-controlled data that did not actually originate from the repository tree.

This report does not claim direct command execution from this code path by itself. The demonstrated impact is metadata injection across the repository boundary.

Recommended fix

A safe fix is to stop silently following symlinks for the worktree .gitmodules path in this loading path.

Reasonable options include:

1. use symlink_metadata() / lstatstyle checks and reject symlinked .gitmodules when loading from the worktree;
2. canonicalize the target and verify that it still resides under the repository worktree before reading it;
3. for security-sensitive callers, prefer loading .gitmodules from the index or HEAD tree rather than following the worktree path.

At minimum, the worktree path should not silently follow symlinks to arbitrary external files.

Summary

attachments: pocs.zip

Submodule names coming from .gitmodules are exposed as unvalidated names and are later reused to derive the submodule git directory as:

<superproject common_dir>/modules/<submodule name>

Because the submodule name is joined directly as a filesystem path component, a name such as ../../../escaped-target.git escapes .git/modules after normalization. The current implementation then uses that escaped path in both state() and open().

The updated PoC demonstrates the real sink, not just string construction:

• state() reports repository_exists=true for the traversed path;
• open() returns a repository whose normalized common_dir() matches the attacker-chosen repository outside .git/modules.

Root cause analysis

The relevant flow is:

1. gix-submodule/src/access.rs exposes unvalidated submodule names from configuration.
2. gix/src/submodule/mod.rs derives the git directory by doing common_dir().join("modules").join(name) with no confinement check.
3. gix/src/submodule/mod.rs uses that derived path during state resolution and repository opening.

There is no normalization-and-confinement step between “submodule name from configuration” and “filesystem path used for repository existence checks / open.” As a result, traversal segments in the submodule name directly influence which repository path is inspected and opened.

Reproduce steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F002.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F002/result.txt.

Key outputs are:

• submodule_name=../../../escaped-target.git
• derived_git_dir_raw=.../.git/modules/../../../escaped-target.git
• derived_git_dir_normalized=.../artifacts/escaped-target.git
• escaped_target=.../artifacts/escaped-target.git
• repository_exists=true
• submodule_opened=true
• opened_common_dir_normalized=.../artifacts/escaped-target.git
• normalized_git_dir_matches_target=true
• opened_common_dir_matches_target=true
• target_outside_modules_root=true

These outputs show that gitoxide is not only constructing a traversable path string. It is actually using the escaped path for repository existence checks and for opening a repository object.

Impact

Confirmed impact:

• a malicious submodule name can redirect submodule state inspection away from .git/modules/<name> to an attacker-chosen repository path outside .git/modules;
• Submodule::state() can report repository existence for the wrong repository;
• Submodule::open() can return a repository object backed by that attacker-chosen path.

This is best described as a path-traversal / repository-confusion issue in submodule repository resolution.

This report does not claim command execution from this behavior alone. The demonstrated impact is repository redirection: callers that enumerate, inspect, or operate on submodules can be steered into using the wrong repository.

Recommended fix

Two complementary fixes are advisable:

1. do not reuse raw submodule names as filesystem path fragments;
   • either use a validated/sanitized name for filesystem derivation,
   • or derive the storage path from a safe identifier instead of the user-controlled name;
2. add an explicit confinement check after path derivation;
   • normalize or canonicalize the candidate path,
   • verify that the result stays under <common_dir>/modules,
   • reject names that contain traversal segments, path separators, or any representation that can escape the modules root.

In short, submodule names may remain opaque configuration identifiers, but they should not be treated as trusted filesystem subpaths.

Summary

attachments: pocs.zip

When Repository::submodules() loads submodule metadata, it prefers the worktree .gitmodules file if that path exists. In the current implementation, the path is read with std::fs::read(), which follows symlinks. As a result, a repository can present a symlinked .gitmodules that points outside the repository, and gitoxide will parse the out-of-repository bytes as submodule configuration.

This is a repository-boundary violation. A caller using the high-level submodule API can believe it is reading repository-local submodule metadata, while the bytes are actually coming from an arbitrary file outside the repository tree.

Root cause analysis

The relevant flow is:

1. gix/src/repository/location.rs derives the worktree .gitmodules path as workdir/.gitmodules.
2. gix/src/repository/submodule.rs reads that path with std::fs::read(&path) and immediately parses the bytes as a submodule configuration file.
3. Repository::submodules() exposes the parsed entries through the high-level API.

The issue is not in the parser. The issue is that the worktree path is treated as an ordinary file without checking whether it is a symlink, and without checking whether the canonicalized target remains inside the repository worktree.

Because std::fs::read() follows symlinks, a malicious repository can cause gitoxide to ingest bytes from an attacker-chosen location outside the repository. The resulting Submodule objects then expose name, path, and url values derived from that external file.

Reproduction steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F001.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F001/result.txt.

Important outputs include:

• gitmodules_symlink=.../victim-repo/.gitmodules
• symlink_target=.../outside/modules.conf
• parsed_name=symlinked
• parsed_path=deps/symlinked
• parsed_url=https://attacker.example/symlinked.git

These outputs show that gitoxide parsed the submodule configuration from the symlink target outside the repository, not from repository-local bytes.

Impact

Confirmed impact:

• out-of-repository bytes can be injected into the result of Repository::submodules();
• callers can be misled about submodule metadata such as name, path, and url;
• any downstream workflow that uses those values to decide clone, fetch, update, or policy behavior is operating on attacker-controlled data that did not actually originate from the repository tree.

This report does not claim direct command execution from this code path by itself. The demonstrated impact is metadata injection across the repository boundary.

Recommended fix

A safe fix is to stop silently following symlinks for the worktree .gitmodules path in this loading path.

Reasonable options include:

1. use symlink_metadata() / lstatstyle checks and reject symlinked .gitmodules when loading from the worktree;
2. canonicalize the target and verify that it still resides under the repository worktree before reading it;
3. for security-sensitive callers, prefer loading .gitmodules from the index or HEAD tree rather than following the worktree path.

At minimum, the worktree path should not silently follow symlinks to arbitrary external files.

Summary

attachments: pocs.zip

Submodule names coming from .gitmodules are exposed as unvalidated names and are later reused to derive the submodule git directory as:

<superproject common_dir>/modules/<submodule name>

Because the submodule name is joined directly as a filesystem path component, a name such as ../../../escaped-target.git escapes .git/modules after normalization. The current implementation then uses that escaped path in both state() and open().

The updated PoC demonstrates the real sink, not just string construction:

• state() reports repository_exists=true for the traversed path;
• open() returns a repository whose normalized common_dir() matches the attacker-chosen repository outside .git/modules.

Root cause analysis

The relevant flow is:

1. gix-submodule/src/access.rs exposes unvalidated submodule names from configuration.
2. gix/src/submodule/mod.rs derives the git directory by doing common_dir().join("modules").join(name) with no confinement check.
3. gix/src/submodule/mod.rs uses that derived path during state resolution and repository opening.

There is no normalization-and-confinement step between “submodule name from configuration” and “filesystem path used for repository existence checks / open.” As a result, traversal segments in the submodule name directly influence which repository path is inspected and opened.

Reproduce steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F002.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F002/result.txt.

Key outputs are:

• submodule_name=../../../escaped-target.git
• derived_git_dir_raw=.../.git/modules/../../../escaped-target.git
• derived_git_dir_normalized=.../artifacts/escaped-target.git
• escaped_target=.../artifacts/escaped-target.git
• repository_exists=true
• submodule_opened=true
• opened_common_dir_normalized=.../artifacts/escaped-target.git
• normalized_git_dir_matches_target=true
• opened_common_dir_matches_target=true
• target_outside_modules_root=true

These outputs show that gitoxide is not only constructing a traversable path string. It is actually using the escaped path for repository existence checks and for opening a repository object.

Impact

Confirmed impact:

• a malicious submodule name can redirect submodule state inspection away from .git/modules/<name> to an attacker-chosen repository path outside .git/modules;
• Submodule::state() can report repository existence for the wrong repository;
• Submodule::open() can return a repository object backed by that attacker-chosen path.

This is best described as a path-traversal / repository-confusion issue in submodule repository resolution.

This report does not claim command execution from this behavior alone. The demonstrated impact is repository redirection: callers that enumerate, inspect, or operate on submodules can be steered into using the wrong repository.

Recommended fix

Two complementary fixes are advisable:

1. do not reuse raw submodule names as filesystem path fragments;
   • either use a validated/sanitized name for filesystem derivation,
   • or derive the storage path from a safe identifier instead of the user-controlled name;
2. add an explicit confinement check after path derivation;
   • normalize or canonicalize the candidate path,
   • verify that the result stays under <common_dir>/modules,
   • reject names that contain traversal segments, path separators, or any representation that can escape the modules root.

In short, submodule names may remain opaque configuration identifiers, but they should not be treated as trusted filesystem subpaths.

Summary

attachments: pocs.zip

When Repository::submodules() loads submodule metadata, it prefers the worktree .gitmodules file if that path exists. In the current implementation, the path is read with std::fs::read(), which follows symlinks. As a result, a repository can present a symlinked .gitmodules that points outside the repository, and gitoxide will parse the out-of-repository bytes as submodule configuration.

This is a repository-boundary violation. A caller using the high-level submodule API can believe it is reading repository-local submodule metadata, while the bytes are actually coming from an arbitrary file outside the repository tree.

Root cause analysis

The relevant flow is:

1. gix/src/repository/location.rs derives the worktree .gitmodules path as workdir/.gitmodules.
2. gix/src/repository/submodule.rs reads that path with std::fs::read(&path) and immediately parses the bytes as a submodule configuration file.
3. Repository::submodules() exposes the parsed entries through the high-level API.

The issue is not in the parser. The issue is that the worktree path is treated as an ordinary file without checking whether it is a symlink, and without checking whether the canonicalized target remains inside the repository worktree.

Because std::fs::read() follows symlinks, a malicious repository can cause gitoxide to ingest bytes from an attacker-chosen location outside the repository. The resulting Submodule objects then expose name, path, and url values derived from that external file.

Reproduction steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F001.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F001/result.txt.

Important outputs include:

• gitmodules_symlink=.../victim-repo/.gitmodules
• symlink_target=.../outside/modules.conf
• parsed_name=symlinked
• parsed_path=deps/symlinked
• parsed_url=https://attacker.example/symlinked.git

These outputs show that gitoxide parsed the submodule configuration from the symlink target outside the repository, not from repository-local bytes.

Impact

Confirmed impact:

• out-of-repository bytes can be injected into the result of Repository::submodules();
• callers can be misled about submodule metadata such as name, path, and url;
• any downstream workflow that uses those values to decide clone, fetch, update, or policy behavior is operating on attacker-controlled data that did not actually originate from the repository tree.

This report does not claim direct command execution from this code path by itself. The demonstrated impact is metadata injection across the repository boundary.

Recommended fix

A safe fix is to stop silently following symlinks for the worktree .gitmodules path in this loading path.

Reasonable options include:

1. use symlink_metadata() / lstatstyle checks and reject symlinked .gitmodules when loading from the worktree;
2. canonicalize the target and verify that it still resides under the repository worktree before reading it;
3. for security-sensitive callers, prefer loading .gitmodules from the index or HEAD tree rather than following the worktree path.

At minimum, the worktree path should not silently follow symlinks to arbitrary external files.

Summary

attachments: pocs.zip

Submodule names coming from .gitmodules are exposed as unvalidated names and are later reused to derive the submodule git directory as:

<superproject common_dir>/modules/<submodule name>

Because the submodule name is joined directly as a filesystem path component, a name such as ../../../escaped-target.git escapes .git/modules after normalization. The current implementation then uses that escaped path in both state() and open().

The updated PoC demonstrates the real sink, not just string construction:

• state() reports repository_exists=true for the traversed path;
• open() returns a repository whose normalized common_dir() matches the attacker-chosen repository outside .git/modules.

Root cause analysis

The relevant flow is:

1. gix-submodule/src/access.rs exposes unvalidated submodule names from configuration.
2. gix/src/submodule/mod.rs derives the git directory by doing common_dir().join("modules").join(name) with no confinement check.
3. gix/src/submodule/mod.rs uses that derived path during state resolution and repository opening.

There is no normalization-and-confinement step between “submodule name from configuration” and “filesystem path used for repository existence checks / open.” As a result, traversal segments in the submodule name directly influence which repository path is inspected and opened.

Reproduce steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F002.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F002/result.txt.

Key outputs are:

• submodule_name=../../../escaped-target.git
• derived_git_dir_raw=.../.git/modules/../../../escaped-target.git
• derived_git_dir_normalized=.../artifacts/escaped-target.git
• escaped_target=.../artifacts/escaped-target.git
• repository_exists=true
• submodule_opened=true
• opened_common_dir_normalized=.../artifacts/escaped-target.git
• normalized_git_dir_matches_target=true
• opened_common_dir_matches_target=true
• target_outside_modules_root=true

These outputs show that gitoxide is not only constructing a traversable path string. It is actually using the escaped path for repository existence checks and for opening a repository object.

Impact

Confirmed impact:

• a malicious submodule name can redirect submodule state inspection away from .git/modules/<name> to an attacker-chosen repository path outside .git/modules;
• Submodule::state() can report repository existence for the wrong repository;
• Submodule::open() can return a repository object backed by that attacker-chosen path.

This is best described as a path-traversal / repository-confusion issue in submodule repository resolution.

This report does not claim command execution from this behavior alone. The demonstrated impact is repository redirection: callers that enumerate, inspect, or operate on submodules can be steered into using the wrong repository.

Recommended fix

Two complementary fixes are advisable:

1. do not reuse raw submodule names as filesystem path fragments;
   • either use a validated/sanitized name for filesystem derivation,
   • or derive the storage path from a safe identifier instead of the user-controlled name;
2. add an explicit confinement check after path derivation;
   • normalize or canonicalize the candidate path,
   • verify that the result stays under <common_dir>/modules,
   • reject names that contain traversal segments, path separators, or any representation that can escape the modules root.

In short, submodule names may remain opaque configuration identifiers, but they should not be treated as trusted filesystem subpaths.

Summary

attachments: pocs.zip

When Repository::submodules() loads submodule metadata, it prefers the worktree .gitmodules file if that path exists. In the current implementation, the path is read with std::fs::read(), which follows symlinks. As a result, a repository can present a symlinked .gitmodules that points outside the repository, and gitoxide will parse the out-of-repository bytes as submodule configuration.

This is a repository-boundary violation. A caller using the high-level submodule API can believe it is reading repository-local submodule metadata, while the bytes are actually coming from an arbitrary file outside the repository tree.

Root cause analysis

The relevant flow is:

1. gix/src/repository/location.rs derives the worktree .gitmodules path as workdir/.gitmodules.
2. gix/src/repository/submodule.rs reads that path with std::fs::read(&path) and immediately parses the bytes as a submodule configuration file.
3. Repository::submodules() exposes the parsed entries through the high-level API.

The issue is not in the parser. The issue is that the worktree path is treated as an ordinary file without checking whether it is a symlink, and without checking whether the canonicalized target remains inside the repository worktree.

Because std::fs::read() follows symlinks, a malicious repository can cause gitoxide to ingest bytes from an attacker-chosen location outside the repository. The resulting Submodule objects then expose name, path, and url values derived from that external file.

Reproduction steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F001.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F001/result.txt.

Important outputs include:

• gitmodules_symlink=.../victim-repo/.gitmodules
• symlink_target=.../outside/modules.conf
• parsed_name=symlinked
• parsed_path=deps/symlinked
• parsed_url=https://attacker.example/symlinked.git

These outputs show that gitoxide parsed the submodule configuration from the symlink target outside the repository, not from repository-local bytes.

Impact

Confirmed impact:

• out-of-repository bytes can be injected into the result of Repository::submodules();
• callers can be misled about submodule metadata such as name, path, and url;
• any downstream workflow that uses those values to decide clone, fetch, update, or policy behavior is operating on attacker-controlled data that did not actually originate from the repository tree.

This report does not claim direct command execution from this code path by itself. The demonstrated impact is metadata injection across the repository boundary.

Recommended fix

A safe fix is to stop silently following symlinks for the worktree .gitmodules path in this loading path.

Reasonable options include:

1. use symlink_metadata() / lstatstyle checks and reject symlinked .gitmodules when loading from the worktree;
2. canonicalize the target and verify that it still resides under the repository worktree before reading it;
3. for security-sensitive callers, prefer loading .gitmodules from the index or HEAD tree rather than following the worktree path.

At minimum, the worktree path should not silently follow symlinks to arbitrary external files.

Summary

attachments: pocs.zip

Submodule names coming from .gitmodules are exposed as unvalidated names and are later reused to derive the submodule git directory as:

<superproject common_dir>/modules/<submodule name>

Because the submodule name is joined directly as a filesystem path component, a name such as ../../../escaped-target.git escapes .git/modules after normalization. The current implementation then uses that escaped path in both state() and open().

The updated PoC demonstrates the real sink, not just string construction:

• state() reports repository_exists=true for the traversed path;
• open() returns a repository whose normalized common_dir() matches the attacker-chosen repository outside .git/modules.

Root cause analysis

The relevant flow is:

1. gix-submodule/src/access.rs exposes unvalidated submodule names from configuration.
2. gix/src/submodule/mod.rs derives the git directory by doing common_dir().join("modules").join(name) with no confinement check.
3. gix/src/submodule/mod.rs uses that derived path during state resolution and repository opening.

There is no normalization-and-confinement step between “submodule name from configuration” and “filesystem path used for repository existence checks / open.” As a result, traversal segments in the submodule name directly influence which repository path is inspected and opened.

Reproduce steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F002.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F002/result.txt.

Key outputs are:

• submodule_name=../../../escaped-target.git
• derived_git_dir_raw=.../.git/modules/../../../escaped-target.git
• derived_git_dir_normalized=.../artifacts/escaped-target.git
• escaped_target=.../artifacts/escaped-target.git
• repository_exists=true
• submodule_opened=true
• opened_common_dir_normalized=.../artifacts/escaped-target.git
• normalized_git_dir_matches_target=true
• opened_common_dir_matches_target=true
• target_outside_modules_root=true

These outputs show that gitoxide is not only constructing a traversable path string. It is actually using the escaped path for repository existence checks and for opening a repository object.

Impact

Confirmed impact:

• a malicious submodule name can redirect submodule state inspection away from .git/modules/<name> to an attacker-chosen repository path outside .git/modules;
• Submodule::state() can report repository existence for the wrong repository;
• Submodule::open() can return a repository object backed by that attacker-chosen path.

This is best described as a path-traversal / repository-confusion issue in submodule repository resolution.

This report does not claim command execution from this behavior alone. The demonstrated impact is repository redirection: callers that enumerate, inspect, or operate on submodules can be steered into using the wrong repository.

Recommended fix

Two complementary fixes are advisable:

1. do not reuse raw submodule names as filesystem path fragments;
   • either use a validated/sanitized name for filesystem derivation,
   • or derive the storage path from a safe identifier instead of the user-controlled name;
2. add an explicit confinement check after path derivation;
   • normalize or canonicalize the candidate path,
   • verify that the result stays under <common_dir>/modules,
   • reject names that contain traversal segments, path separators, or any representation that can escape the modules root.

In short, submodule names may remain opaque configuration identifiers, but they should not be treated as trusted filesystem subpaths.

Summary

attachments: pocs.zip

When Repository::submodules() loads submodule metadata, it prefers the worktree .gitmodules file if that path exists. In the current implementation, the path is read with std::fs::read(), which follows symlinks. As a result, a repository can present a symlinked .gitmodules that points outside the repository, and gitoxide will parse the out-of-repository bytes as submodule configuration.

This is a repository-boundary violation. A caller using the high-level submodule API can believe it is reading repository-local submodule metadata, while the bytes are actually coming from an arbitrary file outside the repository tree.

Root cause analysis

The relevant flow is:

1. gix/src/repository/location.rs derives the worktree .gitmodules path as workdir/.gitmodules.
2. gix/src/repository/submodule.rs reads that path with std::fs::read(&path) and immediately parses the bytes as a submodule configuration file.
3. Repository::submodules() exposes the parsed entries through the high-level API.

The issue is not in the parser. The issue is that the worktree path is treated as an ordinary file without checking whether it is a symlink, and without checking whether the canonicalized target remains inside the repository worktree.

Because std::fs::read() follows symlinks, a malicious repository can cause gitoxide to ingest bytes from an attacker-chosen location outside the repository. The resulting Submodule objects then expose name, path, and url values derived from that external file.

Reproduction steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F001.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F001/result.txt.

Important outputs include:

• gitmodules_symlink=.../victim-repo/.gitmodules
• symlink_target=.../outside/modules.conf
• parsed_name=symlinked
• parsed_path=deps/symlinked
• parsed_url=https://attacker.example/symlinked.git

These outputs show that gitoxide parsed the submodule configuration from the symlink target outside the repository, not from repository-local bytes.

Impact

Confirmed impact:

• out-of-repository bytes can be injected into the result of Repository::submodules();
• callers can be misled about submodule metadata such as name, path, and url;
• any downstream workflow that uses those values to decide clone, fetch, update, or policy behavior is operating on attacker-controlled data that did not actually originate from the repository tree.

This report does not claim direct command execution from this code path by itself. The demonstrated impact is metadata injection across the repository boundary.

Recommended fix

A safe fix is to stop silently following symlinks for the worktree .gitmodules path in this loading path.

Reasonable options include:

1. use symlink_metadata() / lstatstyle checks and reject symlinked .gitmodules when loading from the worktree;
2. canonicalize the target and verify that it still resides under the repository worktree before reading it;
3. for security-sensitive callers, prefer loading .gitmodules from the index or HEAD tree rather than following the worktree path.

At minimum, the worktree path should not silently follow symlinks to arbitrary external files.

Summary

attachments: pocs.zip

Submodule names coming from .gitmodules are exposed as unvalidated names and are later reused to derive the submodule git directory as:

<superproject common_dir>/modules/<submodule name>

Because the submodule name is joined directly as a filesystem path component, a name such as ../../../escaped-target.git escapes .git/modules after normalization. The current implementation then uses that escaped path in both state() and open().

The updated PoC demonstrates the real sink, not just string construction:

• state() reports repository_exists=true for the traversed path;
• open() returns a repository whose normalized common_dir() matches the attacker-chosen repository outside .git/modules.

Root cause analysis

The relevant flow is:

1. gix-submodule/src/access.rs exposes unvalidated submodule names from configuration.
2. gix/src/submodule/mod.rs derives the git directory by doing common_dir().join("modules").join(name) with no confinement check.
3. gix/src/submodule/mod.rs uses that derived path during state resolution and repository opening.

There is no normalization-and-confinement step between “submodule name from configuration” and “filesystem path used for repository existence checks / open.” As a result, traversal segments in the submodule name directly influence which repository path is inspected and opened.

Reproduce steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F002.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F002/result.txt.

Key outputs are:

• submodule_name=../../../escaped-target.git
• derived_git_dir_raw=.../.git/modules/../../../escaped-target.git
• derived_git_dir_normalized=.../artifacts/escaped-target.git
• escaped_target=.../artifacts/escaped-target.git
• repository_exists=true
• submodule_opened=true
• opened_common_dir_normalized=.../artifacts/escaped-target.git
• normalized_git_dir_matches_target=true
• opened_common_dir_matches_target=true
• target_outside_modules_root=true

These outputs show that gitoxide is not only constructing a traversable path string. It is actually using the escaped path for repository existence checks and for opening a repository object.

Impact

Confirmed impact:

• a malicious submodule name can redirect submodule state inspection away from .git/modules/<name> to an attacker-chosen repository path outside .git/modules;
• Submodule::state() can report repository existence for the wrong repository;
• Submodule::open() can return a repository object backed by that attacker-chosen path.

This is best described as a path-traversal / repository-confusion issue in submodule repository resolution.

This report does not claim command execution from this behavior alone. The demonstrated impact is repository redirection: callers that enumerate, inspect, or operate on submodules can be steered into using the wrong repository.

Recommended fix

Two complementary fixes are advisable:

1. do not reuse raw submodule names as filesystem path fragments;
   • either use a validated/sanitized name for filesystem derivation,
   • or derive the storage path from a safe identifier instead of the user-controlled name;
2. add an explicit confinement check after path derivation;
   • normalize or canonicalize the candidate path,
   • verify that the result stays under <common_dir>/modules,
   • reject names that contain traversal segments, path separators, or any representation that can escape the modules root.

In short, submodule names may remain opaque configuration identifiers, but they should not be treated as trusted filesystem subpaths.

Summary

attachments: pocs.zip

When Repository::submodules() loads submodule metadata, it prefers the worktree .gitmodules file if that path exists. In the current implementation, the path is read with std::fs::read(), which follows symlinks. As a result, a repository can present a symlinked .gitmodules that points outside the repository, and gitoxide will parse the out-of-repository bytes as submodule configuration.

This is a repository-boundary violation. A caller using the high-level submodule API can believe it is reading repository-local submodule metadata, while the bytes are actually coming from an arbitrary file outside the repository tree.

Root cause analysis

The relevant flow is:

1. gix/src/repository/location.rs derives the worktree .gitmodules path as workdir/.gitmodules.
2. gix/src/repository/submodule.rs reads that path with std::fs::read(&path) and immediately parses the bytes as a submodule configuration file.
3. Repository::submodules() exposes the parsed entries through the high-level API.

The issue is not in the parser. The issue is that the worktree path is treated as an ordinary file without checking whether it is a symlink, and without checking whether the canonicalized target remains inside the repository worktree.

Because std::fs::read() follows symlinks, a malicious repository can cause gitoxide to ingest bytes from an attacker-chosen location outside the repository. The resulting Submodule objects then expose name, path, and url values derived from that external file.

Reproduction steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F001.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F001/result.txt.

Important outputs include:

• gitmodules_symlink=.../victim-repo/.gitmodules
• symlink_target=.../outside/modules.conf
• parsed_name=symlinked
• parsed_path=deps/symlinked
• parsed_url=https://attacker.example/symlinked.git

These outputs show that gitoxide parsed the submodule configuration from the symlink target outside the repository, not from repository-local bytes.

Impact

Confirmed impact:

• out-of-repository bytes can be injected into the result of Repository::submodules();
• callers can be misled about submodule metadata such as name, path, and url;
• any downstream workflow that uses those values to decide clone, fetch, update, or policy behavior is operating on attacker-controlled data that did not actually originate from the repository tree.

This report does not claim direct command execution from this code path by itself. The demonstrated impact is metadata injection across the repository boundary.

Recommended fix

A safe fix is to stop silently following symlinks for the worktree .gitmodules path in this loading path.

Reasonable options include:

1. use symlink_metadata() / lstatstyle checks and reject symlinked .gitmodules when loading from the worktree;
2. canonicalize the target and verify that it still resides under the repository worktree before reading it;
3. for security-sensitive callers, prefer loading .gitmodules from the index or HEAD tree rather than following the worktree path.

At minimum, the worktree path should not silently follow symlinks to arbitrary external files.

Summary

attachments: pocs.zip

Submodule names coming from .gitmodules are exposed as unvalidated names and are later reused to derive the submodule git directory as:

<superproject common_dir>/modules/<submodule name>

Because the submodule name is joined directly as a filesystem path component, a name such as ../../../escaped-target.git escapes .git/modules after normalization. The current implementation then uses that escaped path in both state() and open().

The updated PoC demonstrates the real sink, not just string construction:

• state() reports repository_exists=true for the traversed path;
• open() returns a repository whose normalized common_dir() matches the attacker-chosen repository outside .git/modules.

Root cause analysis

The relevant flow is:

1. gix-submodule/src/access.rs exposes unvalidated submodule names from configuration.
2. gix/src/submodule/mod.rs derives the git directory by doing common_dir().join("modules").join(name) with no confinement check.
3. gix/src/submodule/mod.rs uses that derived path during state resolution and repository opening.

There is no normalization-and-confinement step between “submodule name from configuration” and “filesystem path used for repository existence checks / open.” As a result, traversal segments in the submodule name directly influence which repository path is inspected and opened.

Reproduce steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F002.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F002/result.txt.

Key outputs are:

• submodule_name=../../../escaped-target.git
• derived_git_dir_raw=.../.git/modules/../../../escaped-target.git
• derived_git_dir_normalized=.../artifacts/escaped-target.git
• escaped_target=.../artifacts/escaped-target.git
• repository_exists=true
• submodule_opened=true
• opened_common_dir_normalized=.../artifacts/escaped-target.git
• normalized_git_dir_matches_target=true
• opened_common_dir_matches_target=true
• target_outside_modules_root=true

These outputs show that gitoxide is not only constructing a traversable path string. It is actually using the escaped path for repository existence checks and for opening a repository object.

Impact

Confirmed impact:

• a malicious submodule name can redirect submodule state inspection away from .git/modules/<name> to an attacker-chosen repository path outside .git/modules;
• Submodule::state() can report repository existence for the wrong repository;
• Submodule::open() can return a repository object backed by that attacker-chosen path.

This is best described as a path-traversal / repository-confusion issue in submodule repository resolution.

This report does not claim command execution from this behavior alone. The demonstrated impact is repository redirection: callers that enumerate, inspect, or operate on submodules can be steered into using the wrong repository.

Recommended fix

Two complementary fixes are advisable:

1. do not reuse raw submodule names as filesystem path fragments;
   • either use a validated/sanitized name for filesystem derivation,
   • or derive the storage path from a safe identifier instead of the user-controlled name;
2. add an explicit confinement check after path derivation;
   • normalize or canonicalize the candidate path,
   • verify that the result stays under <common_dir>/modules,
   • reject names that contain traversal segments, path separators, or any representation that can escape the modules root.

In short, submodule names may remain opaque configuration identifiers, but they should not be treated as trusted filesystem subpaths.

Summary

attachments: pocs.zip

When Repository::submodules() loads submodule metadata, it prefers the worktree .gitmodules file if that path exists. In the current implementation, the path is read with std::fs::read(), which follows symlinks. As a result, a repository can present a symlinked .gitmodules that points outside the repository, and gitoxide will parse the out-of-repository bytes as submodule configuration.

This is a repository-boundary violation. A caller using the high-level submodule API can believe it is reading repository-local submodule metadata, while the bytes are actually coming from an arbitrary file outside the repository tree.

Root cause analysis

The relevant flow is:

1. gix/src/repository/location.rs derives the worktree .gitmodules path as workdir/.gitmodules.
2. gix/src/repository/submodule.rs reads that path with std::fs::read(&path) and immediately parses the bytes as a submodule configuration file.
3. Repository::submodules() exposes the parsed entries through the high-level API.

The issue is not in the parser. The issue is that the worktree path is treated as an ordinary file without checking whether it is a symlink, and without checking whether the canonicalized target remains inside the repository worktree.

Because std::fs::read() follows symlinks, a malicious repository can cause gitoxide to ingest bytes from an attacker-chosen location outside the repository. The resulting Submodule objects then expose name, path, and url values derived from that external file.

Reproduction steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F001.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F001/result.txt.

Important outputs include:

• gitmodules_symlink=.../victim-repo/.gitmodules
• symlink_target=.../outside/modules.conf
• parsed_name=symlinked
• parsed_path=deps/symlinked
• parsed_url=https://attacker.example/symlinked.git

These outputs show that gitoxide parsed the submodule configuration from the symlink target outside the repository, not from repository-local bytes.

Impact

Confirmed impact:

• out-of-repository bytes can be injected into the result of Repository::submodules();
• callers can be misled about submodule metadata such as name, path, and url;
• any downstream workflow that uses those values to decide clone, fetch, update, or policy behavior is operating on attacker-controlled data that did not actually originate from the repository tree.

This report does not claim direct command execution from this code path by itself. The demonstrated impact is metadata injection across the repository boundary.

Recommended fix

A safe fix is to stop silently following symlinks for the worktree .gitmodules path in this loading path.

Reasonable options include:

1. use symlink_metadata() / lstatstyle checks and reject symlinked .gitmodules when loading from the worktree;
2. canonicalize the target and verify that it still resides under the repository worktree before reading it;
3. for security-sensitive callers, prefer loading .gitmodules from the index or HEAD tree rather than following the worktree path.

At minimum, the worktree path should not silently follow symlinks to arbitrary external files.

Summary

attachments: pocs.zip

Submodule names coming from .gitmodules are exposed as unvalidated names and are later reused to derive the submodule git directory as:

<superproject common_dir>/modules/<submodule name>

Because the submodule name is joined directly as a filesystem path component, a name such as ../../../escaped-target.git escapes .git/modules after normalization. The current implementation then uses that escaped path in both state() and open().

The updated PoC demonstrates the real sink, not just string construction:

• state() reports repository_exists=true for the traversed path;
• open() returns a repository whose normalized common_dir() matches the attacker-chosen repository outside .git/modules.

Root cause analysis

The relevant flow is:

1. gix-submodule/src/access.rs exposes unvalidated submodule names from configuration.
2. gix/src/submodule/mod.rs derives the git directory by doing common_dir().join("modules").join(name) with no confinement check.
3. gix/src/submodule/mod.rs uses that derived path during state resolution and repository opening.

There is no normalization-and-confinement step between “submodule name from configuration” and “filesystem path used for repository existence checks / open.” As a result, traversal segments in the submodule name directly influence which repository path is inspected and opened.

Reproduce steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F002.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F002/result.txt.

Key outputs are:

• submodule_name=../../../escaped-target.git
• derived_git_dir_raw=.../.git/modules/../../../escaped-target.git
• derived_git_dir_normalized=.../artifacts/escaped-target.git
• escaped_target=.../artifacts/escaped-target.git
• repository_exists=true
• submodule_opened=true
• opened_common_dir_normalized=.../artifacts/escaped-target.git
• normalized_git_dir_matches_target=true
• opened_common_dir_matches_target=true
• target_outside_modules_root=true

These outputs show that gitoxide is not only constructing a traversable path string. It is actually using the escaped path for repository existence checks and for opening a repository object.

Impact

Confirmed impact:

• a malicious submodule name can redirect submodule state inspection away from .git/modules/<name> to an attacker-chosen repository path outside .git/modules;
• Submodule::state() can report repository existence for the wrong repository;
• Submodule::open() can return a repository object backed by that attacker-chosen path.

This is best described as a path-traversal / repository-confusion issue in submodule repository resolution.

This report does not claim command execution from this behavior alone. The demonstrated impact is repository redirection: callers that enumerate, inspect, or operate on submodules can be steered into using the wrong repository.

Recommended fix

Two complementary fixes are advisable:

1. do not reuse raw submodule names as filesystem path fragments;
   • either use a validated/sanitized name for filesystem derivation,
   • or derive the storage path from a safe identifier instead of the user-controlled name;
2. add an explicit confinement check after path derivation;
   • normalize or canonicalize the candidate path,
   • verify that the result stays under <common_dir>/modules,
   • reject names that contain traversal segments, path separators, or any representation that can escape the modules root.

In short, submodule names may remain opaque configuration identifiers, but they should not be treated as trusted filesystem subpaths.

Summary

attachments: pocs.zip

When Repository::submodules() loads submodule metadata, it prefers the worktree .gitmodules file if that path exists. In the current implementation, the path is read with std::fs::read(), which follows symlinks. As a result, a repository can present a symlinked .gitmodules that points outside the repository, and gitoxide will parse the out-of-repository bytes as submodule configuration.

This is a repository-boundary violation. A caller using the high-level submodule API can believe it is reading repository-local submodule metadata, while the bytes are actually coming from an arbitrary file outside the repository tree.

Root cause analysis

The relevant flow is:

1. gix/src/repository/location.rs derives the worktree .gitmodules path as workdir/.gitmodules.
2. gix/src/repository/submodule.rs reads that path with std::fs::read(&path) and immediately parses the bytes as a submodule configuration file.
3. Repository::submodules() exposes the parsed entries through the high-level API.

The issue is not in the parser. The issue is that the worktree path is treated as an ordinary file without checking whether it is a symlink, and without checking whether the canonicalized target remains inside the repository worktree.

Because std::fs::read() follows symlinks, a malicious repository can cause gitoxide to ingest bytes from an attacker-chosen location outside the repository. The resulting Submodule objects then expose name, path, and url values derived from that external file.

Reproduction steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F001.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F001/result.txt.

Important outputs include:

• gitmodules_symlink=.../victim-repo/.gitmodules
• symlink_target=.../outside/modules.conf
• parsed_name=symlinked
• parsed_path=deps/symlinked
• parsed_url=https://attacker.example/symlinked.git

These outputs show that gitoxide parsed the submodule configuration from the symlink target outside the repository, not from repository-local bytes.

Impact

Confirmed impact:

• out-of-repository bytes can be injected into the result of Repository::submodules();
• callers can be misled about submodule metadata such as name, path, and url;
• any downstream workflow that uses those values to decide clone, fetch, update, or policy behavior is operating on attacker-controlled data that did not actually originate from the repository tree.

This report does not claim direct command execution from this code path by itself. The demonstrated impact is metadata injection across the repository boundary.

Recommended fix

A safe fix is to stop silently following symlinks for the worktree .gitmodules path in this loading path.

Reasonable options include:

1. use symlink_metadata() / lstatstyle checks and reject symlinked .gitmodules when loading from the worktree;
2. canonicalize the target and verify that it still resides under the repository worktree before reading it;
3. for security-sensitive callers, prefer loading .gitmodules from the index or HEAD tree rather than following the worktree path.

At minimum, the worktree path should not silently follow symlinks to arbitrary external files.

Summary

attachments: pocs.zip

Submodule names coming from .gitmodules are exposed as unvalidated names and are later reused to derive the submodule git directory as:

<superproject common_dir>/modules/<submodule name>

Because the submodule name is joined directly as a filesystem path component, a name such as ../../../escaped-target.git escapes .git/modules after normalization. The current implementation then uses that escaped path in both state() and open().

The updated PoC demonstrates the real sink, not just string construction:

• state() reports repository_exists=true for the traversed path;
• open() returns a repository whose normalized common_dir() matches the attacker-chosen repository outside .git/modules.

Root cause analysis

The relevant flow is:

1. gix-submodule/src/access.rs exposes unvalidated submodule names from configuration.
2. gix/src/submodule/mod.rs derives the git directory by doing common_dir().join("modules").join(name) with no confinement check.
3. gix/src/submodule/mod.rs uses that derived path during state resolution and repository opening.

There is no normalization-and-confinement step between “submodule name from configuration” and “filesystem path used for repository existence checks / open.” As a result, traversal segments in the submodule name directly influence which repository path is inspected and opened.

Reproduce steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F002.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F002/result.txt.

Key outputs are:

• submodule_name=../../../escaped-target.git
• derived_git_dir_raw=.../.git/modules/../../../escaped-target.git
• derived_git_dir_normalized=.../artifacts/escaped-target.git
• escaped_target=.../artifacts/escaped-target.git
• repository_exists=true
• submodule_opened=true
• opened_common_dir_normalized=.../artifacts/escaped-target.git
• normalized_git_dir_matches_target=true
• opened_common_dir_matches_target=true
• target_outside_modules_root=true

These outputs show that gitoxide is not only constructing a traversable path string. It is actually using the escaped path for repository existence checks and for opening a repository object.

Impact

Confirmed impact:

• a malicious submodule name can redirect submodule state inspection away from .git/modules/<name> to an attacker-chosen repository path outside .git/modules;
• Submodule::state() can report repository existence for the wrong repository;
• Submodule::open() can return a repository object backed by that attacker-chosen path.

This is best described as a path-traversal / repository-confusion issue in submodule repository resolution.

This report does not claim command execution from this behavior alone. The demonstrated impact is repository redirection: callers that enumerate, inspect, or operate on submodules can be steered into using the wrong repository.

Recommended fix

Two complementary fixes are advisable:

1. do not reuse raw submodule names as filesystem path fragments;
   • either use a validated/sanitized name for filesystem derivation,
   • or derive the storage path from a safe identifier instead of the user-controlled name;
2. add an explicit confinement check after path derivation;
   • normalize or canonicalize the candidate path,
   • verify that the result stays under <common_dir>/modules,
   • reject names that contain traversal segments, path separators, or any representation that can escape the modules root.

In short, submodule names may remain opaque configuration identifiers, but they should not be treated as trusted filesystem subpaths.

Summary

attachments: pocs.zip

When Repository::submodules() loads submodule metadata, it prefers the worktree .gitmodules file if that path exists. In the current implementation, the path is read with std::fs::read(), which follows symlinks. As a result, a repository can present a symlinked .gitmodules that points outside the repository, and gitoxide will parse the out-of-repository bytes as submodule configuration.

This is a repository-boundary violation. A caller using the high-level submodule API can believe it is reading repository-local submodule metadata, while the bytes are actually coming from an arbitrary file outside the repository tree.

Root cause analysis

The relevant flow is:

1. gix/src/repository/location.rs derives the worktree .gitmodules path as workdir/.gitmodules.
2. gix/src/repository/submodule.rs reads that path with std::fs::read(&path) and immediately parses the bytes as a submodule configuration file.
3. Repository::submodules() exposes the parsed entries through the high-level API.

The issue is not in the parser. The issue is that the worktree path is treated as an ordinary file without checking whether it is a symlink, and without checking whether the canonicalized target remains inside the repository worktree.

Because std::fs::read() follows symlinks, a malicious repository can cause gitoxide to ingest bytes from an attacker-chosen location outside the repository. The resulting Submodule objects then expose name, path, and url values derived from that external file.

Reproduction steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F001.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F001/result.txt.

Important outputs include:

• gitmodules_symlink=.../victim-repo/.gitmodules
• symlink_target=.../outside/modules.conf
• parsed_name=symlinked
• parsed_path=deps/symlinked
• parsed_url=https://attacker.example/symlinked.git

These outputs show that gitoxide parsed the submodule configuration from the symlink target outside the repository, not from repository-local bytes.

Impact

Confirmed impact:

• out-of-repository bytes can be injected into the result of Repository::submodules();
• callers can be misled about submodule metadata such as name, path, and url;
• any downstream workflow that uses those values to decide clone, fetch, update, or policy behavior is operating on attacker-controlled data that did not actually originate from the repository tree.

This report does not claim direct command execution from this code path by itself. The demonstrated impact is metadata injection across the repository boundary.

Recommended fix

A safe fix is to stop silently following symlinks for the worktree .gitmodules path in this loading path.

Reasonable options include:

1. use symlink_metadata() / lstatstyle checks and reject symlinked .gitmodules when loading from the worktree;
2. canonicalize the target and verify that it still resides under the repository worktree before reading it;
3. for security-sensitive callers, prefer loading .gitmodules from the index or HEAD tree rather than following the worktree path.

At minimum, the worktree path should not silently follow symlinks to arbitrary external files.

Summary

attachments: pocs.zip

Submodule names coming from .gitmodules are exposed as unvalidated names and are later reused to derive the submodule git directory as:

<superproject common_dir>/modules/<submodule name>

Because the submodule name is joined directly as a filesystem path component, a name such as ../../../escaped-target.git escapes .git/modules after normalization. The current implementation then uses that escaped path in both state() and open().

The updated PoC demonstrates the real sink, not just string construction:

• state() reports repository_exists=true for the traversed path;
• open() returns a repository whose normalized common_dir() matches the attacker-chosen repository outside .git/modules.

Root cause analysis

The relevant flow is:

1. gix-submodule/src/access.rs exposes unvalidated submodule names from configuration.
2. gix/src/submodule/mod.rs derives the git directory by doing common_dir().join("modules").join(name) with no confinement check.
3. gix/src/submodule/mod.rs uses that derived path during state resolution and repository opening.

There is no normalization-and-confinement step between “submodule name from configuration” and “filesystem path used for repository existence checks / open.” As a result, traversal segments in the submodule name directly influence which repository path is inspected and opened.

Reproduce steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F002.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F002/result.txt.

Key outputs are:

• submodule_name=../../../escaped-target.git
• derived_git_dir_raw=.../.git/modules/../../../escaped-target.git
• derived_git_dir_normalized=.../artifacts/escaped-target.git
• escaped_target=.../artifacts/escaped-target.git
• repository_exists=true
• submodule_opened=true
• opened_common_dir_normalized=.../artifacts/escaped-target.git
• normalized_git_dir_matches_target=true
• opened_common_dir_matches_target=true
• target_outside_modules_root=true

These outputs show that gitoxide is not only constructing a traversable path string. It is actually using the escaped path for repository existence checks and for opening a repository object.

Impact

Confirmed impact:

• a malicious submodule name can redirect submodule state inspection away from .git/modules/<name> to an attacker-chosen repository path outside .git/modules;
• Submodule::state() can report repository existence for the wrong repository;
• Submodule::open() can return a repository object backed by that attacker-chosen path.

This is best described as a path-traversal / repository-confusion issue in submodule repository resolution.

This report does not claim command execution from this behavior alone. The demonstrated impact is repository redirection: callers that enumerate, inspect, or operate on submodules can be steered into using the wrong repository.

Recommended fix

Two complementary fixes are advisable:

1. do not reuse raw submodule names as filesystem path fragments;
   • either use a validated/sanitized name for filesystem derivation,
   • or derive the storage path from a safe identifier instead of the user-controlled name;
2. add an explicit confinement check after path derivation;
   • normalize or canonicalize the candidate path,
   • verify that the result stays under <common_dir>/modules,
   • reject names that contain traversal segments, path separators, or any representation that can escape the modules root.

In short, submodule names may remain opaque configuration identifiers, but they should not be treated as trusted filesystem subpaths.

Summary

attachments: pocs.zip

When Repository::submodules() loads submodule metadata, it prefers the worktree .gitmodules file if that path exists. In the current implementation, the path is read with std::fs::read(), which follows symlinks. As a result, a repository can present a symlinked .gitmodules that points outside the repository, and gitoxide will parse the out-of-repository bytes as submodule configuration.

This is a repository-boundary violation. A caller using the high-level submodule API can believe it is reading repository-local submodule metadata, while the bytes are actually coming from an arbitrary file outside the repository tree.

Root cause analysis

The relevant flow is:

1. gix/src/repository/location.rs derives the worktree .gitmodules path as workdir/.gitmodules.
2. gix/src/repository/submodule.rs reads that path with std::fs::read(&path) and immediately parses the bytes as a submodule configuration file.
3. Repository::submodules() exposes the parsed entries through the high-level API.

The issue is not in the parser. The issue is that the worktree path is treated as an ordinary file without checking whether it is a symlink, and without checking whether the canonicalized target remains inside the repository worktree.

Because std::fs::read() follows symlinks, a malicious repository can cause gitoxide to ingest bytes from an attacker-chosen location outside the repository. The resulting Submodule objects then expose name, path, and url values derived from that external file.

Reproduction steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F001.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F001/result.txt.

Important outputs include:

• gitmodules_symlink=.../victim-repo/.gitmodules
• symlink_target=.../outside/modules.conf
• parsed_name=symlinked
• parsed_path=deps/symlinked
• parsed_url=https://attacker.example/symlinked.git

These outputs show that gitoxide parsed the submodule configuration from the symlink target outside the repository, not from repository-local bytes.

Impact

Confirmed impact:

• out-of-repository bytes can be injected into the result of Repository::submodules();
• callers can be misled about submodule metadata such as name, path, and url;
• any downstream workflow that uses those values to decide clone, fetch, update, or policy behavior is operating on attacker-controlled data that did not actually originate from the repository tree.

This report does not claim direct command execution from this code path by itself. The demonstrated impact is metadata injection across the repository boundary.

Recommended fix

A safe fix is to stop silently following symlinks for the worktree .gitmodules path in this loading path.

Reasonable options include:

1. use symlink_metadata() / lstatstyle checks and reject symlinked .gitmodules when loading from the worktree;
2. canonicalize the target and verify that it still resides under the repository worktree before reading it;
3. for security-sensitive callers, prefer loading .gitmodules from the index or HEAD tree rather than following the worktree path.

At minimum, the worktree path should not silently follow symlinks to arbitrary external files.

Summary

gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.

Details

gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide.

The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the sha1collisiondetection algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes.

PoC

The following program demonstrates the problem, using the two SHAttered PDFs:

use sha1_checked::{CollisionResult, Digest};

fn sha1_oid_of_file(filename: &str) -> gix::ObjectId {
    let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1);
    hasher.update(&std::fs::read(filename).unwrap());
    gix::ObjectId::Sha1(hasher.digest())
}

fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> {
    // Matches Git’s behaviour.
    let mut hasher = sha1_checked::Builder::default().safe_hash(false).build();
    hasher.update(&std::fs::read(filename).unwrap());
    match hasher.try_finalize() {
        CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())),
        CollisionResult::Mitigated(_) => unreachable!(),
        CollisionResult::Collision(digest) => Err(format!(
            "Collision attack: {}",
            gix::ObjectId::Sha1(digest.into()).to_hex()
        )),
    }
}

fn main() {
    dbg!(sha1_oid_of_file("shattered-1.pdf"));
    dbg!(sha1_oid_of_file("shattered-2.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-1.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-2.pdf"));
}

The output is as follows:

[src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)
[src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)

The latter behaviour matches Git.

Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources.

Impact

An attacker with the ability to mount a collision attack on SHA-1 like the SHAttered or SHA-1 is a Shambles attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities.

This vulnerability affects any user of gitoxide, including gix-* library crates, that reads or writes Git objects.

Summary

The gix and ein commands write pathnames and other metadata literally to terminals, even if they contain characters terminals treat specially, including ANSI escape sequences. This sometimes allows an untrusted repository to misrepresent its contents and to alter or concoct error messages.

Details

gitoxide-core, which provides most underlying functionality of the gix and ein commands, does not neutralize newlines, backspaces, or control characters—including those that form ANSI escape sequences—that appear in a repository's paths, author and committer names, commit messages, or other metadata. Such text may be written as part of the output of a command, as well as appearing in error messages when an operation fails.

ANSI escape sequences are of particular concern because, when printed to a terminal, they can change colors, including to render subsequent text unreadable; reposition the cursor to write text in a different location, including where text has already been written; clear the terminal; set the terminal title-bar text to arbitrary values; render the terminal temporarily unusable; and other such operations.

The effect is mostly an annoyance. But the author of a malicious repository who can predict how information from the repository may be accessed can cause files in the repository to be concealed or otherwise misrepresented, as well as rewrite all or part of error messages, or mimic error messages convincingly by repositioning the cursor and writing colored text.

PoC

On a Unix-like system in a POSIX-compatible shell, run:

git init misleading-path
cd misleading-path
touch "$(printf '\033]0;Boo!\007\033[2K\r\033[91mError: Repository is corrupted. Run \033[96mEVIL_COMMAND\033[91m to attempt recovery.\033[0m')"
git add .
git commit -m 'Initial commit'

In the repository—or, if desired, in a clone of it, to show that this is exploitable by getting a user to clone an untrusted repository—run this command, which outputs entries in a three-column form showing type, hash, and filename:

gix tree entries

Although the output is of that form, it does not appear to be. Instead, the output in a terminal looks like this, colorized to appear to be an error message, with EVIL_COMMAND in another color, and with no other text:

Error: Repository is corrupted. Run EVIL_COMMAND to attempt recovery.

In some terminals, a beep or other sound will be made. In most terminals, the title bar text will be changed to Boo!, though in some shells this may be immediately undone when printing the prompt. These elements are included to showcase the abilities of ANSI escape sequences, but they are not usually themselves threats.

To see what is actually produced, gix tree entries can be piped to a command that displays special characters symbolically, such as less or cat -v if available.

BLOB e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 ESC]0;Boo!^GESC[2K^MESC[91mError: Repository is corrupted. Run ESC[96mEVIL_COMMANDESC[91m to attempt recovery.ESC[0m

That shows the effect on gix tree entries, but various other commands are also affected, and the escape sequences and other special characters can also appear in non-path metadata, such as in the user.name used to create a commit.

Impact

For users who do not clone or operate in clones of untrusted repositories, there is no impact. Windows is much less affected than Unix-like systems due to limitations on what characters can appear in filenames, and because traditionally Windows terminals do not support as many ANSI escape sequences.

Because different gix and ein commands display different data in different formats, the author of a malicious repository must guess how it will be used, which complicates crafting truly convincing output, though it may be possible to craft a repository where gix clone fails to clone it but produces a misleading message.

Although this is mainly exploitable on systems other than Windows, in the ability to produce misleading output this superficially resembles CVE-2024-35197. But this is much more limited, because:

• The misleading output can only be made to go where the application is already sending output. Redirection is not defeated, and devices to access cannot be chosen by the attacker.
• The misleading output can only be take place when the application is already producing output. This limitation complicates the production of believable messages.
• Only terminals are affected. Even if a standard stream is redirected to another file or device, these special characters would not have a special effect, unless echoed later without sanitization.
• Reading and blocking cannot be performed.
• Applications other than the gitoxide gix and ein executables are unaffected. The exception is if another application uses gitoxide-core. But this is explicitly discouraged in the gitoxide-core documentation and is believed to be rare.

Summary

attachments: pocs.zip

Submodule names coming from .gitmodules are exposed as unvalidated names and are later reused to derive the submodule git directory as:

<superproject common_dir>/modules/<submodule name>

Because the submodule name is joined directly as a filesystem path component, a name such as ../../../escaped-target.git escapes .git/modules after normalization. The current implementation then uses that escaped path in both state() and open().

The updated PoC demonstrates the real sink, not just string construction:

• state() reports repository_exists=true for the traversed path;
• open() returns a repository whose normalized common_dir() matches the attacker-chosen repository outside .git/modules.

Root cause analysis

The relevant flow is:

1. gix-submodule/src/access.rs exposes unvalidated submodule names from configuration.
2. gix/src/submodule/mod.rs derives the git directory by doing common_dir().join("modules").join(name) with no confinement check.
3. gix/src/submodule/mod.rs uses that derived path during state resolution and repository opening.

There is no normalization-and-confinement step between “submodule name from configuration” and “filesystem path used for repository existence checks / open.” As a result, traversal segments in the submodule name directly influence which repository path is inspected and opened.

Reproduce steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F002.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F002/result.txt.

Key outputs are:

• submodule_name=../../../escaped-target.git
• derived_git_dir_raw=.../.git/modules/../../../escaped-target.git
• derived_git_dir_normalized=.../artifacts/escaped-target.git
• escaped_target=.../artifacts/escaped-target.git
• repository_exists=true
• submodule_opened=true
• opened_common_dir_normalized=.../artifacts/escaped-target.git
• normalized_git_dir_matches_target=true
• opened_common_dir_matches_target=true
• target_outside_modules_root=true

These outputs show that gitoxide is not only constructing a traversable path string. It is actually using the escaped path for repository existence checks and for opening a repository object.

Impact

Confirmed impact:

• a malicious submodule name can redirect submodule state inspection away from .git/modules/<name> to an attacker-chosen repository path outside .git/modules;
• Submodule::state() can report repository existence for the wrong repository;
• Submodule::open() can return a repository object backed by that attacker-chosen path.

This is best described as a path-traversal / repository-confusion issue in submodule repository resolution.

This report does not claim command execution from this behavior alone. The demonstrated impact is repository redirection: callers that enumerate, inspect, or operate on submodules can be steered into using the wrong repository.

Recommended fix

Two complementary fixes are advisable:

1. do not reuse raw submodule names as filesystem path fragments;
   • either use a validated/sanitized name for filesystem derivation,
   • or derive the storage path from a safe identifier instead of the user-controlled name;
2. add an explicit confinement check after path derivation;
   • normalize or canonicalize the candidate path,
   • verify that the result stays under <common_dir>/modules,
   • reject names that contain traversal segments, path separators, or any representation that can escape the modules root.

In short, submodule names may remain opaque configuration identifiers, but they should not be treated as trusted filesystem subpaths.

Summary

attachments: pocs.zip

When Repository::submodules() loads submodule metadata, it prefers the worktree .gitmodules file if that path exists. In the current implementation, the path is read with std::fs::read(), which follows symlinks. As a result, a repository can present a symlinked .gitmodules that points outside the repository, and gitoxide will parse the out-of-repository bytes as submodule configuration.

This is a repository-boundary violation. A caller using the high-level submodule API can believe it is reading repository-local submodule metadata, while the bytes are actually coming from an arbitrary file outside the repository tree.

Root cause analysis

The relevant flow is:

1. gix/src/repository/location.rs derives the worktree .gitmodules path as workdir/.gitmodules.
2. gix/src/repository/submodule.rs reads that path with std::fs::read(&path) and immediately parses the bytes as a submodule configuration file.
3. Repository::submodules() exposes the parsed entries through the high-level API.

The issue is not in the parser. The issue is that the worktree path is treated as an ordinary file without checking whether it is a symlink, and without checking whether the canonicalized target remains inside the repository worktree.

Because std::fs::read() follows symlinks, a malicious repository can cause gitoxide to ingest bytes from an attacker-chosen location outside the repository. The resulting Submodule objects then expose name, path, and url values derived from that external file.

Reproduction steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F001.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F001/result.txt.

Important outputs include:

• gitmodules_symlink=.../victim-repo/.gitmodules
• symlink_target=.../outside/modules.conf
• parsed_name=symlinked
• parsed_path=deps/symlinked
• parsed_url=https://attacker.example/symlinked.git

These outputs show that gitoxide parsed the submodule configuration from the symlink target outside the repository, not from repository-local bytes.

Impact

Confirmed impact:

• out-of-repository bytes can be injected into the result of Repository::submodules();
• callers can be misled about submodule metadata such as name, path, and url;
• any downstream workflow that uses those values to decide clone, fetch, update, or policy behavior is operating on attacker-controlled data that did not actually originate from the repository tree.

This report does not claim direct command execution from this code path by itself. The demonstrated impact is metadata injection across the repository boundary.

Recommended fix

A safe fix is to stop silently following symlinks for the worktree .gitmodules path in this loading path.

Reasonable options include:

1. use symlink_metadata() / lstatstyle checks and reject symlinked .gitmodules when loading from the worktree;
2. canonicalize the target and verify that it still resides under the repository worktree before reading it;
3. for security-sensitive callers, prefer loading .gitmodules from the index or HEAD tree rather than following the worktree path.

At minimum, the worktree path should not silently follow symlinks to arbitrary external files.

Summary

gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.

Details

gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide.

The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the sha1collisiondetection algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes.

PoC

The following program demonstrates the problem, using the two SHAttered PDFs:

use sha1_checked::{CollisionResult, Digest};

fn sha1_oid_of_file(filename: &str) -> gix::ObjectId {
    let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1);
    hasher.update(&std::fs::read(filename).unwrap());
    gix::ObjectId::Sha1(hasher.digest())
}

fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> {
    // Matches Git’s behaviour.
    let mut hasher = sha1_checked::Builder::default().safe_hash(false).build();
    hasher.update(&std::fs::read(filename).unwrap());
    match hasher.try_finalize() {
        CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())),
        CollisionResult::Mitigated(_) => unreachable!(),
        CollisionResult::Collision(digest) => Err(format!(
            "Collision attack: {}",
            gix::ObjectId::Sha1(digest.into()).to_hex()
        )),
    }
}

fn main() {
    dbg!(sha1_oid_of_file("shattered-1.pdf"));
    dbg!(sha1_oid_of_file("shattered-2.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-1.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-2.pdf"));
}

The output is as follows:

[src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)
[src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)

The latter behaviour matches Git.

Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources.

Impact

An attacker with the ability to mount a collision attack on SHA-1 like the SHAttered or SHA-1 is a Shambles attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities.

This vulnerability affects any user of gitoxide, including gix-* library crates, that reads or writes Git objects.

Summary

The gix and ein commands write pathnames and other metadata literally to terminals, even if they contain characters terminals treat specially, including ANSI escape sequences. This sometimes allows an untrusted repository to misrepresent its contents and to alter or concoct error messages.

Details

gitoxide-core, which provides most underlying functionality of the gix and ein commands, does not neutralize newlines, backspaces, or control characters—including those that form ANSI escape sequences—that appear in a repository's paths, author and committer names, commit messages, or other metadata. Such text may be written as part of the output of a command, as well as appearing in error messages when an operation fails.

ANSI escape sequences are of particular concern because, when printed to a terminal, they can change colors, including to render subsequent text unreadable; reposition the cursor to write text in a different location, including where text has already been written; clear the terminal; set the terminal title-bar text to arbitrary values; render the terminal temporarily unusable; and other such operations.

The effect is mostly an annoyance. But the author of a malicious repository who can predict how information from the repository may be accessed can cause files in the repository to be concealed or otherwise misrepresented, as well as rewrite all or part of error messages, or mimic error messages convincingly by repositioning the cursor and writing colored text.

PoC

On a Unix-like system in a POSIX-compatible shell, run:

git init misleading-path
cd misleading-path
touch "$(printf '\033]0;Boo!\007\033[2K\r\033[91mError: Repository is corrupted. Run \033[96mEVIL_COMMAND\033[91m to attempt recovery.\033[0m')"
git add .
git commit -m 'Initial commit'

In the repository—or, if desired, in a clone of it, to show that this is exploitable by getting a user to clone an untrusted repository—run this command, which outputs entries in a three-column form showing type, hash, and filename:

gix tree entries

Although the output is of that form, it does not appear to be. Instead, the output in a terminal looks like this, colorized to appear to be an error message, with EVIL_COMMAND in another color, and with no other text:

Error: Repository is corrupted. Run EVIL_COMMAND to attempt recovery.

In some terminals, a beep or other sound will be made. In most terminals, the title bar text will be changed to Boo!, though in some shells this may be immediately undone when printing the prompt. These elements are included to showcase the abilities of ANSI escape sequences, but they are not usually themselves threats.

To see what is actually produced, gix tree entries can be piped to a command that displays special characters symbolically, such as less or cat -v if available.

BLOB e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 ESC]0;Boo!^GESC[2K^MESC[91mError: Repository is corrupted. Run ESC[96mEVIL_COMMANDESC[91m to attempt recovery.ESC[0m

That shows the effect on gix tree entries, but various other commands are also affected, and the escape sequences and other special characters can also appear in non-path metadata, such as in the user.name used to create a commit.

Impact

For users who do not clone or operate in clones of untrusted repositories, there is no impact. Windows is much less affected than Unix-like systems due to limitations on what characters can appear in filenames, and because traditionally Windows terminals do not support as many ANSI escape sequences.

Because different gix and ein commands display different data in different formats, the author of a malicious repository must guess how it will be used, which complicates crafting truly convincing output, though it may be possible to craft a repository where gix clone fails to clone it but produces a misleading message.

Although this is mainly exploitable on systems other than Windows, in the ability to produce misleading output this superficially resembles CVE-2024-35197. But this is much more limited, because:

• The misleading output can only be made to go where the application is already sending output. Redirection is not defeated, and devices to access cannot be chosen by the attacker.
• The misleading output can only be take place when the application is already producing output. This limitation complicates the production of believable messages.
• Only terminals are affected. Even if a standard stream is redirected to another file or device, these special characters would not have a special effect, unless echoed later without sanitization.
• Reading and blocking cannot be performed.
• Applications other than the gitoxide gix and ein executables are unaffected. The exception is if another application uses gitoxide-core. But this is explicitly discouraged in the gitoxide-core documentation and is believed to be rare.

Summary

attachments: pocs.zip

Submodule names coming from .gitmodules are exposed as unvalidated names and are later reused to derive the submodule git directory as:

<superproject common_dir>/modules/<submodule name>

Because the submodule name is joined directly as a filesystem path component, a name such as ../../../escaped-target.git escapes .git/modules after normalization. The current implementation then uses that escaped path in both state() and open().

The updated PoC demonstrates the real sink, not just string construction:

• state() reports repository_exists=true for the traversed path;
• open() returns a repository whose normalized common_dir() matches the attacker-chosen repository outside .git/modules.

Root cause analysis

The relevant flow is:

1. gix-submodule/src/access.rs exposes unvalidated submodule names from configuration.
2. gix/src/submodule/mod.rs derives the git directory by doing common_dir().join("modules").join(name) with no confinement check.
3. gix/src/submodule/mod.rs uses that derived path during state resolution and repository opening.

There is no normalization-and-confinement step between “submodule name from configuration” and “filesystem path used for repository existence checks / open.” As a result, traversal segments in the submodule name directly influence which repository path is inspected and opened.

Reproduce steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F002.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F002/result.txt.

Key outputs are:

• submodule_name=../../../escaped-target.git
• derived_git_dir_raw=.../.git/modules/../../../escaped-target.git
• derived_git_dir_normalized=.../artifacts/escaped-target.git
• escaped_target=.../artifacts/escaped-target.git
• repository_exists=true
• submodule_opened=true
• opened_common_dir_normalized=.../artifacts/escaped-target.git
• normalized_git_dir_matches_target=true
• opened_common_dir_matches_target=true
• target_outside_modules_root=true

These outputs show that gitoxide is not only constructing a traversable path string. It is actually using the escaped path for repository existence checks and for opening a repository object.

Impact

Confirmed impact:

• a malicious submodule name can redirect submodule state inspection away from .git/modules/<name> to an attacker-chosen repository path outside .git/modules;
• Submodule::state() can report repository existence for the wrong repository;
• Submodule::open() can return a repository object backed by that attacker-chosen path.

This is best described as a path-traversal / repository-confusion issue in submodule repository resolution.

This report does not claim command execution from this behavior alone. The demonstrated impact is repository redirection: callers that enumerate, inspect, or operate on submodules can be steered into using the wrong repository.

Recommended fix

Two complementary fixes are advisable:

1. do not reuse raw submodule names as filesystem path fragments;
   • either use a validated/sanitized name for filesystem derivation,
   • or derive the storage path from a safe identifier instead of the user-controlled name;
2. add an explicit confinement check after path derivation;
   • normalize or canonicalize the candidate path,
   • verify that the result stays under <common_dir>/modules,
   • reject names that contain traversal segments, path separators, or any representation that can escape the modules root.

In short, submodule names may remain opaque configuration identifiers, but they should not be treated as trusted filesystem subpaths.

Summary

attachments: pocs.zip

When Repository::submodules() loads submodule metadata, it prefers the worktree .gitmodules file if that path exists. In the current implementation, the path is read with std::fs::read(), which follows symlinks. As a result, a repository can present a symlinked .gitmodules that points outside the repository, and gitoxide will parse the out-of-repository bytes as submodule configuration.

This is a repository-boundary violation. A caller using the high-level submodule API can believe it is reading repository-local submodule metadata, while the bytes are actually coming from an arbitrary file outside the repository tree.

Root cause analysis

The relevant flow is:

1. gix/src/repository/location.rs derives the worktree .gitmodules path as workdir/.gitmodules.
2. gix/src/repository/submodule.rs reads that path with std::fs::read(&path) and immediately parses the bytes as a submodule configuration file.
3. Repository::submodules() exposes the parsed entries through the high-level API.

The issue is not in the parser. The issue is that the worktree path is treated as an ordinary file without checking whether it is a symlink, and without checking whether the canonicalized target remains inside the repository worktree.

Because std::fs::read() follows symlinks, a malicious repository can cause gitoxide to ingest bytes from an attacker-chosen location outside the repository. The resulting Submodule objects then expose name, path, and url values derived from that external file.

Reproduction steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F001.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F001/result.txt.

Important outputs include:

• gitmodules_symlink=.../victim-repo/.gitmodules
• symlink_target=.../outside/modules.conf
• parsed_name=symlinked
• parsed_path=deps/symlinked
• parsed_url=https://attacker.example/symlinked.git

These outputs show that gitoxide parsed the submodule configuration from the symlink target outside the repository, not from repository-local bytes.

Impact

Confirmed impact:

• out-of-repository bytes can be injected into the result of Repository::submodules();
• callers can be misled about submodule metadata such as name, path, and url;
• any downstream workflow that uses those values to decide clone, fetch, update, or policy behavior is operating on attacker-controlled data that did not actually originate from the repository tree.

This report does not claim direct command execution from this code path by itself. The demonstrated impact is metadata injection across the repository boundary.

Recommended fix

A safe fix is to stop silently following symlinks for the worktree .gitmodules path in this loading path.

Reasonable options include:

1. use symlink_metadata() / lstatstyle checks and reject symlinked .gitmodules when loading from the worktree;
2. canonicalize the target and verify that it still resides under the repository worktree before reading it;
3. for security-sensitive callers, prefer loading .gitmodules from the index or HEAD tree rather than following the worktree path.

At minimum, the worktree path should not silently follow symlinks to arbitrary external files.

Summary

gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.

Details

gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide.

The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the sha1collisiondetection algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes.

PoC

The following program demonstrates the problem, using the two SHAttered PDFs:

use sha1_checked::{CollisionResult, Digest};

fn sha1_oid_of_file(filename: &str) -> gix::ObjectId {
    let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1);
    hasher.update(&std::fs::read(filename).unwrap());
    gix::ObjectId::Sha1(hasher.digest())
}

fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> {
    // Matches Git’s behaviour.
    let mut hasher = sha1_checked::Builder::default().safe_hash(false).build();
    hasher.update(&std::fs::read(filename).unwrap());
    match hasher.try_finalize() {
        CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())),
        CollisionResult::Mitigated(_) => unreachable!(),
        CollisionResult::Collision(digest) => Err(format!(
            "Collision attack: {}",
            gix::ObjectId::Sha1(digest.into()).to_hex()
        )),
    }
}

fn main() {
    dbg!(sha1_oid_of_file("shattered-1.pdf"));
    dbg!(sha1_oid_of_file("shattered-2.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-1.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-2.pdf"));
}

The output is as follows:

[src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)
[src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)

The latter behaviour matches Git.

Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources.

Impact

An attacker with the ability to mount a collision attack on SHA-1 like the SHAttered or SHA-1 is a Shambles attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities.

This vulnerability affects any user of gitoxide, including gix-* library crates, that reads or writes Git objects.

Summary

The gix and ein commands write pathnames and other metadata literally to terminals, even if they contain characters terminals treat specially, including ANSI escape sequences. This sometimes allows an untrusted repository to misrepresent its contents and to alter or concoct error messages.

Details

gitoxide-core, which provides most underlying functionality of the gix and ein commands, does not neutralize newlines, backspaces, or control characters—including those that form ANSI escape sequences—that appear in a repository's paths, author and committer names, commit messages, or other metadata. Such text may be written as part of the output of a command, as well as appearing in error messages when an operation fails.

ANSI escape sequences are of particular concern because, when printed to a terminal, they can change colors, including to render subsequent text unreadable; reposition the cursor to write text in a different location, including where text has already been written; clear the terminal; set the terminal title-bar text to arbitrary values; render the terminal temporarily unusable; and other such operations.

The effect is mostly an annoyance. But the author of a malicious repository who can predict how information from the repository may be accessed can cause files in the repository to be concealed or otherwise misrepresented, as well as rewrite all or part of error messages, or mimic error messages convincingly by repositioning the cursor and writing colored text.

PoC

On a Unix-like system in a POSIX-compatible shell, run:

git init misleading-path
cd misleading-path
touch "$(printf '\033]0;Boo!\007\033[2K\r\033[91mError: Repository is corrupted. Run \033[96mEVIL_COMMAND\033[91m to attempt recovery.\033[0m')"
git add .
git commit -m 'Initial commit'

In the repository—or, if desired, in a clone of it, to show that this is exploitable by getting a user to clone an untrusted repository—run this command, which outputs entries in a three-column form showing type, hash, and filename:

gix tree entries

Although the output is of that form, it does not appear to be. Instead, the output in a terminal looks like this, colorized to appear to be an error message, with EVIL_COMMAND in another color, and with no other text:

Error: Repository is corrupted. Run EVIL_COMMAND to attempt recovery.

In some terminals, a beep or other sound will be made. In most terminals, the title bar text will be changed to Boo!, though in some shells this may be immediately undone when printing the prompt. These elements are included to showcase the abilities of ANSI escape sequences, but they are not usually themselves threats.

To see what is actually produced, gix tree entries can be piped to a command that displays special characters symbolically, such as less or cat -v if available.

BLOB e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 ESC]0;Boo!^GESC[2K^MESC[91mError: Repository is corrupted. Run ESC[96mEVIL_COMMANDESC[91m to attempt recovery.ESC[0m

That shows the effect on gix tree entries, but various other commands are also affected, and the escape sequences and other special characters can also appear in non-path metadata, such as in the user.name used to create a commit.

Impact

For users who do not clone or operate in clones of untrusted repositories, there is no impact. Windows is much less affected than Unix-like systems due to limitations on what characters can appear in filenames, and because traditionally Windows terminals do not support as many ANSI escape sequences.

Because different gix and ein commands display different data in different formats, the author of a malicious repository must guess how it will be used, which complicates crafting truly convincing output, though it may be possible to craft a repository where gix clone fails to clone it but produces a misleading message.

Although this is mainly exploitable on systems other than Windows, in the ability to produce misleading output this superficially resembles CVE-2024-35197. But this is much more limited, because:

• The misleading output can only be made to go where the application is already sending output. Redirection is not defeated, and devices to access cannot be chosen by the attacker.
• The misleading output can only be take place when the application is already producing output. This limitation complicates the production of believable messages.
• Only terminals are affected. Even if a standard stream is redirected to another file or device, these special characters would not have a special effect, unless echoed later without sanitization.
• Reading and blocking cannot be performed.
• Applications other than the gitoxide gix and ein executables are unaffected. The exception is if another application uses gitoxide-core. But this is explicitly discouraged in the gitoxide-core documentation and is believed to be rare.

Summary

attachments: pocs.zip

Submodule names coming from .gitmodules are exposed as unvalidated names and are later reused to derive the submodule git directory as:

<superproject common_dir>/modules/<submodule name>

Because the submodule name is joined directly as a filesystem path component, a name such as ../../../escaped-target.git escapes .git/modules after normalization. The current implementation then uses that escaped path in both state() and open().

The updated PoC demonstrates the real sink, not just string construction:

• state() reports repository_exists=true for the traversed path;
• open() returns a repository whose normalized common_dir() matches the attacker-chosen repository outside .git/modules.

Root cause analysis

The relevant flow is:

1. gix-submodule/src/access.rs exposes unvalidated submodule names from configuration.
2. gix/src/submodule/mod.rs derives the git directory by doing common_dir().join("modules").join(name) with no confinement check.
3. gix/src/submodule/mod.rs uses that derived path during state resolution and repository opening.

There is no normalization-and-confinement step between “submodule name from configuration” and “filesystem path used for repository existence checks / open.” As a result, traversal segments in the submodule name directly influence which repository path is inspected and opened.

Reproduce steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F002.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F002/result.txt.

Key outputs are:

• submodule_name=../../../escaped-target.git
• derived_git_dir_raw=.../.git/modules/../../../escaped-target.git
• derived_git_dir_normalized=.../artifacts/escaped-target.git
• escaped_target=.../artifacts/escaped-target.git
• repository_exists=true
• submodule_opened=true
• opened_common_dir_normalized=.../artifacts/escaped-target.git
• normalized_git_dir_matches_target=true
• opened_common_dir_matches_target=true
• target_outside_modules_root=true

These outputs show that gitoxide is not only constructing a traversable path string. It is actually using the escaped path for repository existence checks and for opening a repository object.

Impact

Confirmed impact:

• a malicious submodule name can redirect submodule state inspection away from .git/modules/<name> to an attacker-chosen repository path outside .git/modules;
• Submodule::state() can report repository existence for the wrong repository;
• Submodule::open() can return a repository object backed by that attacker-chosen path.

This is best described as a path-traversal / repository-confusion issue in submodule repository resolution.

This report does not claim command execution from this behavior alone. The demonstrated impact is repository redirection: callers that enumerate, inspect, or operate on submodules can be steered into using the wrong repository.

Recommended fix

Two complementary fixes are advisable:

1. do not reuse raw submodule names as filesystem path fragments;
   • either use a validated/sanitized name for filesystem derivation,
   • or derive the storage path from a safe identifier instead of the user-controlled name;
2. add an explicit confinement check after path derivation;
   • normalize or canonicalize the candidate path,
   • verify that the result stays under <common_dir>/modules,
   • reject names that contain traversal segments, path separators, or any representation that can escape the modules root.

In short, submodule names may remain opaque configuration identifiers, but they should not be treated as trusted filesystem subpaths.

Summary

attachments: pocs.zip

When Repository::submodules() loads submodule metadata, it prefers the worktree .gitmodules file if that path exists. In the current implementation, the path is read with std::fs::read(), which follows symlinks. As a result, a repository can present a symlinked .gitmodules that points outside the repository, and gitoxide will parse the out-of-repository bytes as submodule configuration.

This is a repository-boundary violation. A caller using the high-level submodule API can believe it is reading repository-local submodule metadata, while the bytes are actually coming from an arbitrary file outside the repository tree.

Root cause analysis

The relevant flow is:

1. gix/src/repository/location.rs derives the worktree .gitmodules path as workdir/.gitmodules.
2. gix/src/repository/submodule.rs reads that path with std::fs::read(&path) and immediately parses the bytes as a submodule configuration file.
3. Repository::submodules() exposes the parsed entries through the high-level API.

The issue is not in the parser. The issue is that the worktree path is treated as an ordinary file without checking whether it is a symlink, and without checking whether the canonicalized target remains inside the repository worktree.

Because std::fs::read() follows symlinks, a malicious repository can cause gitoxide to ingest bytes from an attacker-chosen location outside the repository. The resulting Submodule objects then expose name, path, and url values derived from that external file.

Reproduction steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F001.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F001/result.txt.

Important outputs include:

• gitmodules_symlink=.../victim-repo/.gitmodules
• symlink_target=.../outside/modules.conf
• parsed_name=symlinked
• parsed_path=deps/symlinked
• parsed_url=https://attacker.example/symlinked.git

These outputs show that gitoxide parsed the submodule configuration from the symlink target outside the repository, not from repository-local bytes.

Impact

Confirmed impact:

• out-of-repository bytes can be injected into the result of Repository::submodules();
• callers can be misled about submodule metadata such as name, path, and url;
• any downstream workflow that uses those values to decide clone, fetch, update, or policy behavior is operating on attacker-controlled data that did not actually originate from the repository tree.

This report does not claim direct command execution from this code path by itself. The demonstrated impact is metadata injection across the repository boundary.

Recommended fix

A safe fix is to stop silently following symlinks for the worktree .gitmodules path in this loading path.

Reasonable options include:

1. use symlink_metadata() / lstatstyle checks and reject symlinked .gitmodules when loading from the worktree;
2. canonicalize the target and verify that it still resides under the repository worktree before reading it;
3. for security-sensitive callers, prefer loading .gitmodules from the index or HEAD tree rather than following the worktree path.

At minimum, the worktree path should not silently follow symlinks to arbitrary external files.

Summary

gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.

Details

gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide.

The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the sha1collisiondetection algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes.

PoC

The following program demonstrates the problem, using the two SHAttered PDFs:

use sha1_checked::{CollisionResult, Digest};

fn sha1_oid_of_file(filename: &str) -> gix::ObjectId {
    let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1);
    hasher.update(&std::fs::read(filename).unwrap());
    gix::ObjectId::Sha1(hasher.digest())
}

fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> {
    // Matches Git’s behaviour.
    let mut hasher = sha1_checked::Builder::default().safe_hash(false).build();
    hasher.update(&std::fs::read(filename).unwrap());
    match hasher.try_finalize() {
        CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())),
        CollisionResult::Mitigated(_) => unreachable!(),
        CollisionResult::Collision(digest) => Err(format!(
            "Collision attack: {}",
            gix::ObjectId::Sha1(digest.into()).to_hex()
        )),
    }
}

fn main() {
    dbg!(sha1_oid_of_file("shattered-1.pdf"));
    dbg!(sha1_oid_of_file("shattered-2.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-1.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-2.pdf"));
}

The output is as follows:

[src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)
[src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)

The latter behaviour matches Git.

Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources.

Impact

An attacker with the ability to mount a collision attack on SHA-1 like the SHAttered or SHA-1 is a Shambles attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities.

This vulnerability affects any user of gitoxide, including gix-* library crates, that reads or writes Git objects.

Summary

The gix and ein commands write pathnames and other metadata literally to terminals, even if they contain characters terminals treat specially, including ANSI escape sequences. This sometimes allows an untrusted repository to misrepresent its contents and to alter or concoct error messages.

Details

gitoxide-core, which provides most underlying functionality of the gix and ein commands, does not neutralize newlines, backspaces, or control characters—including those that form ANSI escape sequences—that appear in a repository's paths, author and committer names, commit messages, or other metadata. Such text may be written as part of the output of a command, as well as appearing in error messages when an operation fails.

ANSI escape sequences are of particular concern because, when printed to a terminal, they can change colors, including to render subsequent text unreadable; reposition the cursor to write text in a different location, including where text has already been written; clear the terminal; set the terminal title-bar text to arbitrary values; render the terminal temporarily unusable; and other such operations.

The effect is mostly an annoyance. But the author of a malicious repository who can predict how information from the repository may be accessed can cause files in the repository to be concealed or otherwise misrepresented, as well as rewrite all or part of error messages, or mimic error messages convincingly by repositioning the cursor and writing colored text.

PoC

On a Unix-like system in a POSIX-compatible shell, run:

git init misleading-path
cd misleading-path
touch "$(printf '\033]0;Boo!\007\033[2K\r\033[91mError: Repository is corrupted. Run \033[96mEVIL_COMMAND\033[91m to attempt recovery.\033[0m')"
git add .
git commit -m 'Initial commit'

In the repository—or, if desired, in a clone of it, to show that this is exploitable by getting a user to clone an untrusted repository—run this command, which outputs entries in a three-column form showing type, hash, and filename:

gix tree entries

Although the output is of that form, it does not appear to be. Instead, the output in a terminal looks like this, colorized to appear to be an error message, with EVIL_COMMAND in another color, and with no other text:

Error: Repository is corrupted. Run EVIL_COMMAND to attempt recovery.

In some terminals, a beep or other sound will be made. In most terminals, the title bar text will be changed to Boo!, though in some shells this may be immediately undone when printing the prompt. These elements are included to showcase the abilities of ANSI escape sequences, but they are not usually themselves threats.

To see what is actually produced, gix tree entries can be piped to a command that displays special characters symbolically, such as less or cat -v if available.

BLOB e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 ESC]0;Boo!^GESC[2K^MESC[91mError: Repository is corrupted. Run ESC[96mEVIL_COMMANDESC[91m to attempt recovery.ESC[0m

That shows the effect on gix tree entries, but various other commands are also affected, and the escape sequences and other special characters can also appear in non-path metadata, such as in the user.name used to create a commit.

Impact

For users who do not clone or operate in clones of untrusted repositories, there is no impact. Windows is much less affected than Unix-like systems due to limitations on what characters can appear in filenames, and because traditionally Windows terminals do not support as many ANSI escape sequences.

Because different gix and ein commands display different data in different formats, the author of a malicious repository must guess how it will be used, which complicates crafting truly convincing output, though it may be possible to craft a repository where gix clone fails to clone it but produces a misleading message.

Although this is mainly exploitable on systems other than Windows, in the ability to produce misleading output this superficially resembles CVE-2024-35197. But this is much more limited, because:

• The misleading output can only be made to go where the application is already sending output. Redirection is not defeated, and devices to access cannot be chosen by the attacker.
• The misleading output can only be take place when the application is already producing output. This limitation complicates the production of believable messages.
• Only terminals are affected. Even if a standard stream is redirected to another file or device, these special characters would not have a special effect, unless echoed later without sanitization.
• Reading and blocking cannot be performed.
• Applications other than the gitoxide gix and ein executables are unaffected. The exception is if another application uses gitoxide-core. But this is explicitly discouraged in the gitoxide-core documentation and is believed to be rare.

Summary

attachments: pocs.zip

Submodule names coming from .gitmodules are exposed as unvalidated names and are later reused to derive the submodule git directory as:

<superproject common_dir>/modules/<submodule name>

Because the submodule name is joined directly as a filesystem path component, a name such as ../../../escaped-target.git escapes .git/modules after normalization. The current implementation then uses that escaped path in both state() and open().

The updated PoC demonstrates the real sink, not just string construction:

• state() reports repository_exists=true for the traversed path;
• open() returns a repository whose normalized common_dir() matches the attacker-chosen repository outside .git/modules.

Root cause analysis

The relevant flow is:

1. gix-submodule/src/access.rs exposes unvalidated submodule names from configuration.
2. gix/src/submodule/mod.rs derives the git directory by doing common_dir().join("modules").join(name) with no confinement check.
3. gix/src/submodule/mod.rs uses that derived path during state resolution and repository opening.

There is no normalization-and-confinement step between “submodule name from configuration” and “filesystem path used for repository existence checks / open.” As a result, traversal segments in the submodule name directly influence which repository path is inspected and opened.

Reproduce steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F002.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F002/result.txt.

Key outputs are:

• submodule_name=../../../escaped-target.git
• derived_git_dir_raw=.../.git/modules/../../../escaped-target.git
• derived_git_dir_normalized=.../artifacts/escaped-target.git
• escaped_target=.../artifacts/escaped-target.git
• repository_exists=true
• submodule_opened=true
• opened_common_dir_normalized=.../artifacts/escaped-target.git
• normalized_git_dir_matches_target=true
• opened_common_dir_matches_target=true
• target_outside_modules_root=true

These outputs show that gitoxide is not only constructing a traversable path string. It is actually using the escaped path for repository existence checks and for opening a repository object.

Impact

Confirmed impact:

• a malicious submodule name can redirect submodule state inspection away from .git/modules/<name> to an attacker-chosen repository path outside .git/modules;
• Submodule::state() can report repository existence for the wrong repository;
• Submodule::open() can return a repository object backed by that attacker-chosen path.

This is best described as a path-traversal / repository-confusion issue in submodule repository resolution.

This report does not claim command execution from this behavior alone. The demonstrated impact is repository redirection: callers that enumerate, inspect, or operate on submodules can be steered into using the wrong repository.

Recommended fix

Two complementary fixes are advisable:

1. do not reuse raw submodule names as filesystem path fragments;
   • either use a validated/sanitized name for filesystem derivation,
   • or derive the storage path from a safe identifier instead of the user-controlled name;
2. add an explicit confinement check after path derivation;
   • normalize or canonicalize the candidate path,
   • verify that the result stays under <common_dir>/modules,
   • reject names that contain traversal segments, path separators, or any representation that can escape the modules root.

In short, submodule names may remain opaque configuration identifiers, but they should not be treated as trusted filesystem subpaths.

Summary

attachments: pocs.zip

When Repository::submodules() loads submodule metadata, it prefers the worktree .gitmodules file if that path exists. In the current implementation, the path is read with std::fs::read(), which follows symlinks. As a result, a repository can present a symlinked .gitmodules that points outside the repository, and gitoxide will parse the out-of-repository bytes as submodule configuration.

This is a repository-boundary violation. A caller using the high-level submodule API can believe it is reading repository-local submodule metadata, while the bytes are actually coming from an arbitrary file outside the repository tree.

Root cause analysis

The relevant flow is:

1. gix/src/repository/location.rs derives the worktree .gitmodules path as workdir/.gitmodules.
2. gix/src/repository/submodule.rs reads that path with std::fs::read(&path) and immediately parses the bytes as a submodule configuration file.
3. Repository::submodules() exposes the parsed entries through the high-level API.

The issue is not in the parser. The issue is that the worktree path is treated as an ordinary file without checking whether it is a symlink, and without checking whether the canonicalized target remains inside the repository worktree.

Because std::fs::read() follows symlinks, a malicious repository can cause gitoxide to ingest bytes from an attacker-chosen location outside the repository. The resulting Submodule objects then expose name, path, and url values derived from that external file.

Reproduction steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F001.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F001/result.txt.

Important outputs include:

• gitmodules_symlink=.../victim-repo/.gitmodules
• symlink_target=.../outside/modules.conf
• parsed_name=symlinked
• parsed_path=deps/symlinked
• parsed_url=https://attacker.example/symlinked.git

These outputs show that gitoxide parsed the submodule configuration from the symlink target outside the repository, not from repository-local bytes.

Impact

Confirmed impact:

• out-of-repository bytes can be injected into the result of Repository::submodules();
• callers can be misled about submodule metadata such as name, path, and url;
• any downstream workflow that uses those values to decide clone, fetch, update, or policy behavior is operating on attacker-controlled data that did not actually originate from the repository tree.

This report does not claim direct command execution from this code path by itself. The demonstrated impact is metadata injection across the repository boundary.

Recommended fix

A safe fix is to stop silently following symlinks for the worktree .gitmodules path in this loading path.

Reasonable options include:

1. use symlink_metadata() / lstatstyle checks and reject symlinked .gitmodules when loading from the worktree;
2. canonicalize the target and verify that it still resides under the repository worktree before reading it;
3. for security-sensitive callers, prefer loading .gitmodules from the index or HEAD tree rather than following the worktree path.

At minimum, the worktree path should not silently follow symlinks to arbitrary external files.

Summary

gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.

Details

gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide.

The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the sha1collisiondetection algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes.

PoC

The following program demonstrates the problem, using the two SHAttered PDFs:

use sha1_checked::{CollisionResult, Digest};

fn sha1_oid_of_file(filename: &str) -> gix::ObjectId {
    let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1);
    hasher.update(&std::fs::read(filename).unwrap());
    gix::ObjectId::Sha1(hasher.digest())
}

fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> {
    // Matches Git’s behaviour.
    let mut hasher = sha1_checked::Builder::default().safe_hash(false).build();
    hasher.update(&std::fs::read(filename).unwrap());
    match hasher.try_finalize() {
        CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())),
        CollisionResult::Mitigated(_) => unreachable!(),
        CollisionResult::Collision(digest) => Err(format!(
            "Collision attack: {}",
            gix::ObjectId::Sha1(digest.into()).to_hex()
        )),
    }
}

fn main() {
    dbg!(sha1_oid_of_file("shattered-1.pdf"));
    dbg!(sha1_oid_of_file("shattered-2.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-1.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-2.pdf"));
}

The output is as follows:

[src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)
[src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)

The latter behaviour matches Git.

Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources.

Impact

An attacker with the ability to mount a collision attack on SHA-1 like the SHAttered or SHA-1 is a Shambles attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities.

This vulnerability affects any user of gitoxide, including gix-* library crates, that reads or writes Git objects.

Summary

The gix and ein commands write pathnames and other metadata literally to terminals, even if they contain characters terminals treat specially, including ANSI escape sequences. This sometimes allows an untrusted repository to misrepresent its contents and to alter or concoct error messages.

Details

gitoxide-core, which provides most underlying functionality of the gix and ein commands, does not neutralize newlines, backspaces, or control characters—including those that form ANSI escape sequences—that appear in a repository's paths, author and committer names, commit messages, or other metadata. Such text may be written as part of the output of a command, as well as appearing in error messages when an operation fails.

ANSI escape sequences are of particular concern because, when printed to a terminal, they can change colors, including to render subsequent text unreadable; reposition the cursor to write text in a different location, including where text has already been written; clear the terminal; set the terminal title-bar text to arbitrary values; render the terminal temporarily unusable; and other such operations.

The effect is mostly an annoyance. But the author of a malicious repository who can predict how information from the repository may be accessed can cause files in the repository to be concealed or otherwise misrepresented, as well as rewrite all or part of error messages, or mimic error messages convincingly by repositioning the cursor and writing colored text.

PoC

On a Unix-like system in a POSIX-compatible shell, run:

git init misleading-path
cd misleading-path
touch "$(printf '\033]0;Boo!\007\033[2K\r\033[91mError: Repository is corrupted. Run \033[96mEVIL_COMMAND\033[91m to attempt recovery.\033[0m')"
git add .
git commit -m 'Initial commit'

In the repository—or, if desired, in a clone of it, to show that this is exploitable by getting a user to clone an untrusted repository—run this command, which outputs entries in a three-column form showing type, hash, and filename:

gix tree entries

Although the output is of that form, it does not appear to be. Instead, the output in a terminal looks like this, colorized to appear to be an error message, with EVIL_COMMAND in another color, and with no other text:

Error: Repository is corrupted. Run EVIL_COMMAND to attempt recovery.

In some terminals, a beep or other sound will be made. In most terminals, the title bar text will be changed to Boo!, though in some shells this may be immediately undone when printing the prompt. These elements are included to showcase the abilities of ANSI escape sequences, but they are not usually themselves threats.

To see what is actually produced, gix tree entries can be piped to a command that displays special characters symbolically, such as less or cat -v if available.

BLOB e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 ESC]0;Boo!^GESC[2K^MESC[91mError: Repository is corrupted. Run ESC[96mEVIL_COMMANDESC[91m to attempt recovery.ESC[0m

That shows the effect on gix tree entries, but various other commands are also affected, and the escape sequences and other special characters can also appear in non-path metadata, such as in the user.name used to create a commit.

Impact

For users who do not clone or operate in clones of untrusted repositories, there is no impact. Windows is much less affected than Unix-like systems due to limitations on what characters can appear in filenames, and because traditionally Windows terminals do not support as many ANSI escape sequences.

Because different gix and ein commands display different data in different formats, the author of a malicious repository must guess how it will be used, which complicates crafting truly convincing output, though it may be possible to craft a repository where gix clone fails to clone it but produces a misleading message.

Although this is mainly exploitable on systems other than Windows, in the ability to produce misleading output this superficially resembles CVE-2024-35197. But this is much more limited, because:

• The misleading output can only be made to go where the application is already sending output. Redirection is not defeated, and devices to access cannot be chosen by the attacker.
• The misleading output can only be take place when the application is already producing output. This limitation complicates the production of believable messages.
• Only terminals are affected. Even if a standard stream is redirected to another file or device, these special characters would not have a special effect, unless echoed later without sanitization.
• Reading and blocking cannot be performed.
• Applications other than the gitoxide gix and ein executables are unaffected. The exception is if another application uses gitoxide-core. But this is explicitly discouraged in the gitoxide-core documentation and is believed to be rare.

Summary

attachments: pocs.zip

Submodule names coming from .gitmodules are exposed as unvalidated names and are later reused to derive the submodule git directory as:

<superproject common_dir>/modules/<submodule name>

Because the submodule name is joined directly as a filesystem path component, a name such as ../../../escaped-target.git escapes .git/modules after normalization. The current implementation then uses that escaped path in both state() and open().

The updated PoC demonstrates the real sink, not just string construction:

• state() reports repository_exists=true for the traversed path;
• open() returns a repository whose normalized common_dir() matches the attacker-chosen repository outside .git/modules.

Root cause analysis

The relevant flow is:

1. gix-submodule/src/access.rs exposes unvalidated submodule names from configuration.
2. gix/src/submodule/mod.rs derives the git directory by doing common_dir().join("modules").join(name) with no confinement check.
3. gix/src/submodule/mod.rs uses that derived path during state resolution and repository opening.

There is no normalization-and-confinement step between “submodule name from configuration” and “filesystem path used for repository existence checks / open.” As a result, traversal segments in the submodule name directly influence which repository path is inspected and opened.

Reproduce steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F002.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F002/result.txt.

Key outputs are:

• submodule_name=../../../escaped-target.git
• derived_git_dir_raw=.../.git/modules/../../../escaped-target.git
• derived_git_dir_normalized=.../artifacts/escaped-target.git
• escaped_target=.../artifacts/escaped-target.git
• repository_exists=true
• submodule_opened=true
• opened_common_dir_normalized=.../artifacts/escaped-target.git
• normalized_git_dir_matches_target=true
• opened_common_dir_matches_target=true
• target_outside_modules_root=true

These outputs show that gitoxide is not only constructing a traversable path string. It is actually using the escaped path for repository existence checks and for opening a repository object.

Impact

Confirmed impact:

• a malicious submodule name can redirect submodule state inspection away from .git/modules/<name> to an attacker-chosen repository path outside .git/modules;
• Submodule::state() can report repository existence for the wrong repository;
• Submodule::open() can return a repository object backed by that attacker-chosen path.

This is best described as a path-traversal / repository-confusion issue in submodule repository resolution.

This report does not claim command execution from this behavior alone. The demonstrated impact is repository redirection: callers that enumerate, inspect, or operate on submodules can be steered into using the wrong repository.

Recommended fix

Two complementary fixes are advisable:

1. do not reuse raw submodule names as filesystem path fragments;
   • either use a validated/sanitized name for filesystem derivation,
   • or derive the storage path from a safe identifier instead of the user-controlled name;
2. add an explicit confinement check after path derivation;
   • normalize or canonicalize the candidate path,
   • verify that the result stays under <common_dir>/modules,
   • reject names that contain traversal segments, path separators, or any representation that can escape the modules root.

In short, submodule names may remain opaque configuration identifiers, but they should not be treated as trusted filesystem subpaths.

Summary

attachments: pocs.zip

When Repository::submodules() loads submodule metadata, it prefers the worktree .gitmodules file if that path exists. In the current implementation, the path is read with std::fs::read(), which follows symlinks. As a result, a repository can present a symlinked .gitmodules that points outside the repository, and gitoxide will parse the out-of-repository bytes as submodule configuration.

This is a repository-boundary violation. A caller using the high-level submodule API can believe it is reading repository-local submodule metadata, while the bytes are actually coming from an arbitrary file outside the repository tree.

Root cause analysis

The relevant flow is:

1. gix/src/repository/location.rs derives the worktree .gitmodules path as workdir/.gitmodules.
2. gix/src/repository/submodule.rs reads that path with std::fs::read(&path) and immediately parses the bytes as a submodule configuration file.
3. Repository::submodules() exposes the parsed entries through the high-level API.

The issue is not in the parser. The issue is that the worktree path is treated as an ordinary file without checking whether it is a symlink, and without checking whether the canonicalized target remains inside the repository worktree.

Because std::fs::read() follows symlinks, a malicious repository can cause gitoxide to ingest bytes from an attacker-chosen location outside the repository. The resulting Submodule objects then expose name, path, and url values derived from that external file.

Reproduction steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F001.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F001/result.txt.

Important outputs include:

• gitmodules_symlink=.../victim-repo/.gitmodules
• symlink_target=.../outside/modules.conf
• parsed_name=symlinked
• parsed_path=deps/symlinked
• parsed_url=https://attacker.example/symlinked.git

These outputs show that gitoxide parsed the submodule configuration from the symlink target outside the repository, not from repository-local bytes.

Impact

Confirmed impact:

• out-of-repository bytes can be injected into the result of Repository::submodules();
• callers can be misled about submodule metadata such as name, path, and url;
• any downstream workflow that uses those values to decide clone, fetch, update, or policy behavior is operating on attacker-controlled data that did not actually originate from the repository tree.

This report does not claim direct command execution from this code path by itself. The demonstrated impact is metadata injection across the repository boundary.

Recommended fix

A safe fix is to stop silently following symlinks for the worktree .gitmodules path in this loading path.

Reasonable options include:

1. use symlink_metadata() / lstatstyle checks and reject symlinked .gitmodules when loading from the worktree;
2. canonicalize the target and verify that it still resides under the repository worktree before reading it;
3. for security-sensitive callers, prefer loading .gitmodules from the index or HEAD tree rather than following the worktree path.

At minimum, the worktree path should not silently follow symlinks to arbitrary external files.

Summary

gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.

Details

gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide.

The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the sha1collisiondetection algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes.

PoC

The following program demonstrates the problem, using the two SHAttered PDFs:

use sha1_checked::{CollisionResult, Digest};

fn sha1_oid_of_file(filename: &str) -> gix::ObjectId {
    let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1);
    hasher.update(&std::fs::read(filename).unwrap());
    gix::ObjectId::Sha1(hasher.digest())
}

fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> {
    // Matches Git’s behaviour.
    let mut hasher = sha1_checked::Builder::default().safe_hash(false).build();
    hasher.update(&std::fs::read(filename).unwrap());
    match hasher.try_finalize() {
        CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())),
        CollisionResult::Mitigated(_) => unreachable!(),
        CollisionResult::Collision(digest) => Err(format!(
            "Collision attack: {}",
            gix::ObjectId::Sha1(digest.into()).to_hex()
        )),
    }
}

fn main() {
    dbg!(sha1_oid_of_file("shattered-1.pdf"));
    dbg!(sha1_oid_of_file("shattered-2.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-1.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-2.pdf"));
}

The output is as follows:

[src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)
[src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)

The latter behaviour matches Git.

Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources.

Impact

An attacker with the ability to mount a collision attack on SHA-1 like the SHAttered or SHA-1 is a Shambles attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities.

This vulnerability affects any user of gitoxide, including gix-* library crates, that reads or writes Git objects.

Summary

The gix and ein commands write pathnames and other metadata literally to terminals, even if they contain characters terminals treat specially, including ANSI escape sequences. This sometimes allows an untrusted repository to misrepresent its contents and to alter or concoct error messages.

Details

gitoxide-core, which provides most underlying functionality of the gix and ein commands, does not neutralize newlines, backspaces, or control characters—including those that form ANSI escape sequences—that appear in a repository's paths, author and committer names, commit messages, or other metadata. Such text may be written as part of the output of a command, as well as appearing in error messages when an operation fails.

ANSI escape sequences are of particular concern because, when printed to a terminal, they can change colors, including to render subsequent text unreadable; reposition the cursor to write text in a different location, including where text has already been written; clear the terminal; set the terminal title-bar text to arbitrary values; render the terminal temporarily unusable; and other such operations.

The effect is mostly an annoyance. But the author of a malicious repository who can predict how information from the repository may be accessed can cause files in the repository to be concealed or otherwise misrepresented, as well as rewrite all or part of error messages, or mimic error messages convincingly by repositioning the cursor and writing colored text.

PoC

On a Unix-like system in a POSIX-compatible shell, run:

git init misleading-path
cd misleading-path
touch "$(printf '\033]0;Boo!\007\033[2K\r\033[91mError: Repository is corrupted. Run \033[96mEVIL_COMMAND\033[91m to attempt recovery.\033[0m')"
git add .
git commit -m 'Initial commit'

In the repository—or, if desired, in a clone of it, to show that this is exploitable by getting a user to clone an untrusted repository—run this command, which outputs entries in a three-column form showing type, hash, and filename:

gix tree entries

Although the output is of that form, it does not appear to be. Instead, the output in a terminal looks like this, colorized to appear to be an error message, with EVIL_COMMAND in another color, and with no other text:

Error: Repository is corrupted. Run EVIL_COMMAND to attempt recovery.

In some terminals, a beep or other sound will be made. In most terminals, the title bar text will be changed to Boo!, though in some shells this may be immediately undone when printing the prompt. These elements are included to showcase the abilities of ANSI escape sequences, but they are not usually themselves threats.

To see what is actually produced, gix tree entries can be piped to a command that displays special characters symbolically, such as less or cat -v if available.

BLOB e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 ESC]0;Boo!^GESC[2K^MESC[91mError: Repository is corrupted. Run ESC[96mEVIL_COMMANDESC[91m to attempt recovery.ESC[0m

That shows the effect on gix tree entries, but various other commands are also affected, and the escape sequences and other special characters can also appear in non-path metadata, such as in the user.name used to create a commit.

Impact

For users who do not clone or operate in clones of untrusted repositories, there is no impact. Windows is much less affected than Unix-like systems due to limitations on what characters can appear in filenames, and because traditionally Windows terminals do not support as many ANSI escape sequences.

Because different gix and ein commands display different data in different formats, the author of a malicious repository must guess how it will be used, which complicates crafting truly convincing output, though it may be possible to craft a repository where gix clone fails to clone it but produces a misleading message.

Although this is mainly exploitable on systems other than Windows, in the ability to produce misleading output this superficially resembles CVE-2024-35197. But this is much more limited, because:

• The misleading output can only be made to go where the application is already sending output. Redirection is not defeated, and devices to access cannot be chosen by the attacker.
• The misleading output can only be take place when the application is already producing output. This limitation complicates the production of believable messages.
• Only terminals are affected. Even if a standard stream is redirected to another file or device, these special characters would not have a special effect, unless echoed later without sanitization.
• Reading and blocking cannot be performed.
• Applications other than the gitoxide gix and ein executables are unaffected. The exception is if another application uses gitoxide-core. But this is explicitly discouraged in the gitoxide-core documentation and is believed to be rare.

Summary

attachments: pocs.zip

Submodule names coming from .gitmodules are exposed as unvalidated names and are later reused to derive the submodule git directory as:

<superproject common_dir>/modules/<submodule name>

Because the submodule name is joined directly as a filesystem path component, a name such as ../../../escaped-target.git escapes .git/modules after normalization. The current implementation then uses that escaped path in both state() and open().

The updated PoC demonstrates the real sink, not just string construction:

• state() reports repository_exists=true for the traversed path;
• open() returns a repository whose normalized common_dir() matches the attacker-chosen repository outside .git/modules.

Root cause analysis

The relevant flow is:

1. gix-submodule/src/access.rs exposes unvalidated submodule names from configuration.
2. gix/src/submodule/mod.rs derives the git directory by doing common_dir().join("modules").join(name) with no confinement check.
3. gix/src/submodule/mod.rs uses that derived path during state resolution and repository opening.

There is no normalization-and-confinement step between “submodule name from configuration” and “filesystem path used for repository existence checks / open.” As a result, traversal segments in the submodule name directly influence which repository path is inspected and opened.

Reproduce steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F002.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F002/result.txt.

Key outputs are:

• submodule_name=../../../escaped-target.git
• derived_git_dir_raw=.../.git/modules/../../../escaped-target.git
• derived_git_dir_normalized=.../artifacts/escaped-target.git
• escaped_target=.../artifacts/escaped-target.git
• repository_exists=true
• submodule_opened=true
• opened_common_dir_normalized=.../artifacts/escaped-target.git
• normalized_git_dir_matches_target=true
• opened_common_dir_matches_target=true
• target_outside_modules_root=true

These outputs show that gitoxide is not only constructing a traversable path string. It is actually using the escaped path for repository existence checks and for opening a repository object.

Impact

Confirmed impact:

• a malicious submodule name can redirect submodule state inspection away from .git/modules/<name> to an attacker-chosen repository path outside .git/modules;
• Submodule::state() can report repository existence for the wrong repository;
• Submodule::open() can return a repository object backed by that attacker-chosen path.

This is best described as a path-traversal / repository-confusion issue in submodule repository resolution.

This report does not claim command execution from this behavior alone. The demonstrated impact is repository redirection: callers that enumerate, inspect, or operate on submodules can be steered into using the wrong repository.

Recommended fix

Two complementary fixes are advisable:

1. do not reuse raw submodule names as filesystem path fragments;
   • either use a validated/sanitized name for filesystem derivation,
   • or derive the storage path from a safe identifier instead of the user-controlled name;
2. add an explicit confinement check after path derivation;
   • normalize or canonicalize the candidate path,
   • verify that the result stays under <common_dir>/modules,
   • reject names that contain traversal segments, path separators, or any representation that can escape the modules root.

In short, submodule names may remain opaque configuration identifiers, but they should not be treated as trusted filesystem subpaths.

Summary

attachments: pocs.zip

When Repository::submodules() loads submodule metadata, it prefers the worktree .gitmodules file if that path exists. In the current implementation, the path is read with std::fs::read(), which follows symlinks. As a result, a repository can present a symlinked .gitmodules that points outside the repository, and gitoxide will parse the out-of-repository bytes as submodule configuration.

This is a repository-boundary violation. A caller using the high-level submodule API can believe it is reading repository-local submodule metadata, while the bytes are actually coming from an arbitrary file outside the repository tree.

Root cause analysis

The relevant flow is:

1. gix/src/repository/location.rs derives the worktree .gitmodules path as workdir/.gitmodules.
2. gix/src/repository/submodule.rs reads that path with std::fs::read(&path) and immediately parses the bytes as a submodule configuration file.
3. Repository::submodules() exposes the parsed entries through the high-level API.

The issue is not in the parser. The issue is that the worktree path is treated as an ordinary file without checking whether it is a symlink, and without checking whether the canonicalized target remains inside the repository worktree.

Because std::fs::read() follows symlinks, a malicious repository can cause gitoxide to ingest bytes from an attacker-chosen location outside the repository. The resulting Submodule objects then expose name, path, and url values derived from that external file.

Reproduction steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F001.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F001/result.txt.

Important outputs include:

• gitmodules_symlink=.../victim-repo/.gitmodules
• symlink_target=.../outside/modules.conf
• parsed_name=symlinked
• parsed_path=deps/symlinked
• parsed_url=https://attacker.example/symlinked.git

These outputs show that gitoxide parsed the submodule configuration from the symlink target outside the repository, not from repository-local bytes.

Impact

Confirmed impact:

• out-of-repository bytes can be injected into the result of Repository::submodules();
• callers can be misled about submodule metadata such as name, path, and url;
• any downstream workflow that uses those values to decide clone, fetch, update, or policy behavior is operating on attacker-controlled data that did not actually originate from the repository tree.

This report does not claim direct command execution from this code path by itself. The demonstrated impact is metadata injection across the repository boundary.

Recommended fix

A safe fix is to stop silently following symlinks for the worktree .gitmodules path in this loading path.

Reasonable options include:

1. use symlink_metadata() / lstatstyle checks and reject symlinked .gitmodules when loading from the worktree;
2. canonicalize the target and verify that it still resides under the repository worktree before reading it;
3. for security-sensitive callers, prefer loading .gitmodules from the index or HEAD tree rather than following the worktree path.

At minimum, the worktree path should not silently follow symlinks to arbitrary external files.

Summary

gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.

Details

gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide.

The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the sha1collisiondetection algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes.

PoC

The following program demonstrates the problem, using the two SHAttered PDFs:

use sha1_checked::{CollisionResult, Digest};

fn sha1_oid_of_file(filename: &str) -> gix::ObjectId {
    let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1);
    hasher.update(&std::fs::read(filename).unwrap());
    gix::ObjectId::Sha1(hasher.digest())
}

fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> {
    // Matches Git’s behaviour.
    let mut hasher = sha1_checked::Builder::default().safe_hash(false).build();
    hasher.update(&std::fs::read(filename).unwrap());
    match hasher.try_finalize() {
        CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())),
        CollisionResult::Mitigated(_) => unreachable!(),
        CollisionResult::Collision(digest) => Err(format!(
            "Collision attack: {}",
            gix::ObjectId::Sha1(digest.into()).to_hex()
        )),
    }
}

fn main() {
    dbg!(sha1_oid_of_file("shattered-1.pdf"));
    dbg!(sha1_oid_of_file("shattered-2.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-1.pdf"));
    dbg!(sha1dc_oid_of_file("shattered-2.pdf"));
}

The output is as follows:

[src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a)
[src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)
[src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err(
    "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a",
)

The latter behaviour matches Git.

Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources.

Impact

An attacker with the ability to mount a collision attack on SHA-1 like the SHAttered or SHA-1 is a Shambles attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities.

This vulnerability affects any user of gitoxide, including gix-* library crates, that reads or writes Git objects.

Summary

The gix and ein commands write pathnames and other metadata literally to terminals, even if they contain characters terminals treat specially, including ANSI escape sequences. This sometimes allows an untrusted repository to misrepresent its contents and to alter or concoct error messages.

Details

gitoxide-core, which provides most underlying functionality of the gix and ein commands, does not neutralize newlines, backspaces, or control characters—including those that form ANSI escape sequences—that appear in a repository's paths, author and committer names, commit messages, or other metadata. Such text may be written as part of the output of a command, as well as appearing in error messages when an operation fails.

ANSI escape sequences are of particular concern because, when printed to a terminal, they can change colors, including to render subsequent text unreadable; reposition the cursor to write text in a different location, including where text has already been written; clear the terminal; set the terminal title-bar text to arbitrary values; render the terminal temporarily unusable; and other such operations.

The effect is mostly an annoyance. But the author of a malicious repository who can predict how information from the repository may be accessed can cause files in the repository to be concealed or otherwise misrepresented, as well as rewrite all or part of error messages, or mimic error messages convincingly by repositioning the cursor and writing colored text.

PoC

On a Unix-like system in a POSIX-compatible shell, run:

git init misleading-path
cd misleading-path
touch "$(printf '\033]0;Boo!\007\033[2K\r\033[91mError: Repository is corrupted. Run \033[96mEVIL_COMMAND\033[91m to attempt recovery.\033[0m')"
git add .
git commit -m 'Initial commit'

In the repository—or, if desired, in a clone of it, to show that this is exploitable by getting a user to clone an untrusted repository—run this command, which outputs entries in a three-column form showing type, hash, and filename:

gix tree entries

Although the output is of that form, it does not appear to be. Instead, the output in a terminal looks like this, colorized to appear to be an error message, with EVIL_COMMAND in another color, and with no other text:

Error: Repository is corrupted. Run EVIL_COMMAND to attempt recovery.

In some terminals, a beep or other sound will be made. In most terminals, the title bar text will be changed to Boo!, though in some shells this may be immediately undone when printing the prompt. These elements are included to showcase the abilities of ANSI escape sequences, but they are not usually themselves threats.

To see what is actually produced, gix tree entries can be piped to a command that displays special characters symbolically, such as less or cat -v if available.

BLOB e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 ESC]0;Boo!^GESC[2K^MESC[91mError: Repository is corrupted. Run ESC[96mEVIL_COMMANDESC[91m to attempt recovery.ESC[0m

That shows the effect on gix tree entries, but various other commands are also affected, and the escape sequences and other special characters can also appear in non-path metadata, such as in the user.name used to create a commit.

Impact

For users who do not clone or operate in clones of untrusted repositories, there is no impact. Windows is much less affected than Unix-like systems due to limitations on what characters can appear in filenames, and because traditionally Windows terminals do not support as many ANSI escape sequences.

Because different gix and ein commands display different data in different formats, the author of a malicious repository must guess how it will be used, which complicates crafting truly convincing output, though it may be possible to craft a repository where gix clone fails to clone it but produces a misleading message.

Although this is mainly exploitable on systems other than Windows, in the ability to produce misleading output this superficially resembles CVE-2024-35197. But this is much more limited, because:

• The misleading output can only be made to go where the application is already sending output. Redirection is not defeated, and devices to access cannot be chosen by the attacker.
• The misleading output can only be take place when the application is already producing output. This limitation complicates the production of believable messages.
• Only terminals are affected. Even if a standard stream is redirected to another file or device, these special characters would not have a special effect, unless echoed later without sanitization.
• Reading and blocking cannot be performed.
• Applications other than the gitoxide gix and ein executables are unaffected. The exception is if another application uses gitoxide-core. But this is explicitly discouraged in the gitoxide-core documentation and is believed to be rare.

Summary

On Windows, fetching refs that clash with legacy device names reads from the devices, and checking out paths that clash with such names writes arbitrary data to the devices. This allows a repository, when cloned, to cause indefinite blocking or the production of arbitrary message that appear to have come from the application, and potentially other harmful effects under limited circumstances.

Details

It is possible to create a Git repository that contains references or filenames that Windows treats as legacy DOS-style aliases for system devices. When such a repository is cloned:

• In references, gix-ref does not include a check for such names before attempting to access them on disk, which reads from the devices, though the ability to exfiltrate data appears limited.
• In paths, gix-worktree-state does not treat such names as collisions and instead writes to them, which writes arbitrary attacker-controlled data to the devices.

Some such device names refer to devices that are often absent or inaccessible. But a few are guaranteed to be available, allowing some attacks to be carried out with low complexity. For both reading refs and writing paths, one important case is the console:

• Reading a ref whose last component (e.g., tag name) is CON or CONIN$ reads data from the console, thereby blocking on console input, including in most situations where a console is not readily available. This may facilitate denial of service attacks.
• Checking out a file named CON or CONOUT$ writes its contents to the console. This allows an untrusted repository to produce arbitrary text that appears to be a message from the application. Such text may facilitate social engineering if it is selected to instruct the user to perform a particular action.

Another potentially important case is serial ports. For example, COM1 refers to the first serial port, if present. A malicious repository may be able to disrupt intended use of serial ports or attempt to interact with a device. In some configurations, it may be possible to interfere with the operation of a physical or virtual serial console. On Windows, local access to serial ports is often permitted even for limited user accounts without elevation.

Naming Files, Paths, and Namespaces covers most reserved names. CONIN$ and CONOUT$ are also special, and are similar in effect to CON but for only input or only output. These names are case-insensitive and can also be accessed with file extensions (e.g, CON.txt is equivalent to CON) and with some variations involving added spaces or colons.

PoC

Ref example

Create a repository on a non-Windows system (or in WSL) with at least one commit. Use git tag CON to create a lightweight tag named CON. Place the repository somewhere it can be cloned on Windows. A file:// URL is sufficient for testing if a private remote is unavailable. If using git push, pass --tags so the remote has the tag.

On a Windows system, clone the repository with gix clone. This command will block immediately, reading input from the console. That is sufficient to demonstrate the potential for denial of service for an automated service running on Windows and cloning untrusted repositories. The experiment can be stopped with Ctrl+C.

However, if desired, input can be provided. Ending input with Ctrl+Z followed by Enter will cause it to be passed to the application. This will lead to an error message, the specific details of which vary by whether the input is empty or nonempty, and whether it matches or does not match the hexadecimal hash of the tagged commit.

Path example

Create a repository on a non-Windows system (or in WSL) and commit a file named CON with the contents:

warning: data loss imminent; you should run EVIL_COMMAND to back up your work!

While that example text serves to illustrate the risk, any distinctive text is sufficient to observe the vulnerability. Place the repository somewhere it can be cloned on Windows. As above, a file:// URL is sufficient.

On a Windows system, clone the repository with gix clone. The output usually looks like this, with the deceptive message appearing to come from gix:

warning: data loss imminent; you should run EVIL_COMMAND to back up your work!
 04:45:15 indexing done 3.0 objects in 0.00s (12.1K objects/s)
 04:45:15 decompressing done 309B in 0.00s (1.2MB/s)
 04:45:15     Resolving done 3.0 objects in 0.05s (58.0 objects/s)
 04:45:15      Decoding done 309B in 0.05s (6.0KB/s)
 04:45:15 writing index file done 1.2KB in 0.00s (7.0MB/s)
 04:45:15  create index file done 3.0 objects in 0.05s (55.0 objects/s)
 04:45:15          read pack done 294B in 0.05s (5.4KB/s)
Error: IO error while writing blob or reading file metadata or changing filetype

Caused by:
    Incorrect function. (os error 1)

The exact placement of the message is nondeterministic. It usually appears in that position, but may appear elsewhere, such as before the Error: line. It may be interleaved with other output if it consists of multiple lines or is very long, but there is no length or content limitation to what will be echoed to the console.

Impact

If Windows is not used, or untrusted repositories are not cloned or otherwise used, then there is no impact.

The impact is expected to be limited in common configurations, but may vary widely depending on what devices exist, how they are being used, how much knowledge an attacker has of the precise details of their use, and whether the user is likely to trust information that appears in a console. Accessing devices through refs is expected to be less dangerous than accessing them through filenames, since it is trivial to attempt to write arbitrary data using filenames.

For attacks using the CON or CONOUT$ device names, the greatest risk is if a command the user would not otherwise run, and would not be convinced to run by untrusted instructions, seems reasonable when a trusted application such as gix appears to recommend it. The user may then be misled into running an attacker's command.

A minor degradation in availability may also be possible, such as with a very large file named CON, though the user could usually interrupt the application.

Summary

During checkout, gitoxide does not verify that paths point to locations in the working tree. A specially crafted repository can, when cloned, place new files anywhere writable by the application.

Details

Although gix-worktree-state checks for collisions with existing files, it does not itself check if a path is really in the working tree when performing a checkout, nor do the path checks in gix-fs and gix-worktree prevent this. Cloning an untrusted repository containing specially crafted tree or blob names will create new files outside the repository, or inside the repository or a submodule's .git directory. The simplest cases are:

• A tree named .. to traverse upward. This facilitates arbitrary code execution because files can be placed in one or more locations where they are likely to be executed soon.
• A tree named .git to enter a .git directory. This facilitates arbitrary code execution because hooks can be installed.

A number of alternatives that achieve the same effect are also possible, some of which correspond to specific vulnerabilities that have affected Git in the past:

• A tree or blob whose name contains one or more /, to traverse upward or downward. For example, even without containing any tree named .. or .git, a repository can represent a file named ../outside or .git/hooks/pre-commit. This is distinct from the more intuitive case a repository containing trees that represent those paths.
• In Windows, a tree or blob whose name contains one or more \, to traverse upward or downward. (Unlike /, these are valid on other systems.) See GHSA-xjx4-8694-q2fq.
• On a case-insensitive filesystem (such as NTFS, APFS, or HFS+), a tree named as a case variant of .git.
• On HFS+, a tree named like .git or a case variant, with characters added that HFS+ ignores in collation. See https://github.com/git/git/commit/6162a1d323d24fd8cbbb1a6145a91fb849b2568f.
• On NTFS, a tree equivalent to .git (or a case variant) by the use of NTFS stream notation, such as .git::$INDEX_ALLOCATION. See GHSA-5wph-8frv-58vj.
• On an NTFS volume with 8.3 aliasing enabled, a tree named as git~1 (or a case variant). See GHSA-589j-mmg9-733v.

When a checkout creates some files outside the repository directory but fails to complete, the repository directory is usually removed, but the outside files remain.

PoC

For simplicity, these examples stage a stand-in file with a valid name, modify the index, and commit. The instructions assume sed supports -i, which is the case on most systems. If using Windows, a Git Bash shell should be used.

Example: Downward traversal to install hooks

1. Create a new repository with git init dangerous-repo-installs-hook and cd into the directory.
2. Create the stand-in called .git@hooks@pre-commit, with the contents:

   #!/bin/sh
   printf 'Vulnerable!\n'
   date >vulnerable
   

3. Stage the stand-in: git add --chmod=+x .git@hooks@pre-commit
4. Edit the index: env LC_ALL=C sed -i.orig 's|\.git@hooks@pre-commit|.git/hooks/pre-commit|' .git/index
5. Commit: git commit -m 'Initial commit'
6. Optionally, push to a private remote.

Then, on another or the same machine:

1. Clone the repository with a gix clone … command.
2. Enter the newly created directory.
3. Optionally run ls -l .git/hooks to observe that the pre-commit hook is already present.
4. Make a new file and commit it with git. This causes the payload surreptitiously installed as a pre-commit hook to run, printing the message Vulnerable! and creating a file in the current directory containing the current date and time.

Note that the effect is not limited to modifying the current directory. The payload could be written to perform any action that the user who runs git commit is capable of.

Example: Upward traversal to create a file above the working tree

1. Create a new repository with git init dangerous-repo-reaches-up, and cd into the directory.
2. Create the stand-in: echo 'A file outside the working tree, somehow.' >..@outside
3. Stage the stand-in: git add ..@outside
4. Edit the index: env LC_ALL=C sed -i.orig 's|\.\.@outside|../outside|' .git/index
5. Commit: git commit -m 'Initial commit'
6. Optionally, push to a private remote.

Then, as above, on the same or another machine, clone the repository with a gix clone … command. Observe that a file named outside is present alongside (not inside) the cloned directory.

Impact

Any use of gix or another application that makes use of gix-worktree-state, or otherwise relies on gix-fs and gix-worktree for validation, is affected, if used to clone untrusted repositories. The above description focuses on code execution, as that leads to a complete loss of confidentiality, integrity, and availability, but creating files outside a working tree without attempting to execute code can directly impact integrity as well.

In use cases where no untrusted repository is ever cloned, this vulnerability has no impact. Furthermore, the impact of this vulnerability may be lower when gix is used to clone a repository for CI/CD purposes, even if untrusted, since in such uses the environment is usually isolated and arbitrary code is usually run deliberately from the repository with necessary safeguards in place.

Summary

attachments: pocs.zip

Submodule names coming from .gitmodules are exposed as unvalidated names and are later reused to derive the submodule git directory as:

<superproject common_dir>/modules/<submodule name>

Because the submodule name is joined directly as a filesystem path component, a name such as ../../../escaped-target.git escapes .git/modules after normalization. The current implementation then uses that escaped path in both state() and open().

The updated PoC demonstrates the real sink, not just string construction:

• state() reports repository_exists=true for the traversed path;
• open() returns a repository whose normalized common_dir() matches the attacker-chosen repository outside .git/modules.

Root cause analysis

The relevant flow is:

1. gix-submodule/src/access.rs exposes unvalidated submodule names from configuration.
2. gix/src/submodule/mod.rs derives the git directory by doing common_dir().join("modules").join(name) with no confinement check.
3. gix/src/submodule/mod.rs uses that derived path during state resolution and repository opening.

There is no normalization-and-confinement step between “submodule name from configuration” and “filesystem path used for repository existence checks / open.” As a result, traversal segments in the submodule name directly influence which repository path is inspected and opened.

Reproduce steps

Use the attached PoC zip that contains the pocs/ workspace.

1. Unzip the PoC archive.

2. Enter pocs/F002.

3. Run:

   cargo run --quiet
   

4. Compare the output with pocs/F002/result.txt.

Key outputs are:

• submodule_name=../../../escaped-target.git
• derived_git_dir_raw=.../.git/modules/../../../escaped-target.git
• derived_git_dir_normalized=.../artifacts/escaped-target.git
• escaped_target=.../artifacts/escaped-target.git
• repository_exists=true
• submodule_opened=true
• opened_common_dir_normalized=.../artifacts/escaped-target.git
• normalized_git_dir_matches_target=true
• opened_common_dir_matches_target=true
• target_outside_modules_root=true

These outputs show that gitoxide is not only constructing a traversable path string. It is actually using the escaped path for repository existence checks and for opening a repository object.

Impact

Confirmed impact:

• a malicious submodule name can redirect submodule state inspection away from .git/modules/<name> to an attacker-chosen repository path outside .git/modules;
• Submodule::state() can report repository existence for the wrong repository;
• Submodule::open() can return a repository object backed by that attacker-chosen path.

This is best described as a path-traversal / repository-confusion issue in submodule repository resolution.

This report does not claim command execution from this behavior alone. The demonstrated impact is repository redirection: callers that enumerate, inspect, or operate on submodules can be steered into using the wrong repository.

Recommended fix

Two complementary fixes are advisable:

1. do not reuse raw submodule names as filesystem path fragments;
   • either use a validated/sanitized name for filesystem derivation,
   • or derive the storage path from a safe identifier instead of the user-controlled name;
2. add an explicit confinement check after path derivation;
   • normalize or canonicalize the candidate path,
   • verify that the result stays under <common_dir>/modules,
   • reject names that contain traversal segments, path separators, or any representation that can escape the modules root.

In short, submodule names may remain opaque configuration identifiers, but they should not be treated as trusted filesystem subpaths.

Summary

attachments: pocs.zip