Submodule name validation bypass plus missing validation in production code paths allows path traversal via crafted .gitmodules. Combined with a trust inheritance flaw in Submodule::open(), this enables reading arbitrary git repository configs (including credentials) from traversed paths with full trust (CWE-22, CWE-200).
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 …
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 …
gix_submodule::File::update() is the API that gates whether an attacker-supplied .gitmodules file may set update = !<shell command>. The function is designed to return Err(CommandForbiddenInModulesConfiguration) unless the !command value came from a trusted local source (.git/config). Git CVE CVE-2019-19604 illustrates why this check is necessary. However, the guard is implemented incorrectly: it checks whether any section with the same submodule name exists from a non-.gitmodules source; it does not verify that …
gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks.
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.
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.
gix-transport does not check the username part of a URL for text that the external ssh program would interpret as an option. A specially crafted clone URL can smuggle options to SSH. The possibilities are syntactically limited, but if a malicious clone URL is used by an application whose current working directory contains a malicious file, arbitrary code execution occurs.