Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
8 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
In the gix crate, Cache::protectoptions() in gix/src/config/cache/access.rs reads the three filesystem path-protection settings (core.protectHFS, core.protectNTFS, and gitoxide.core.protectWindows) with the unfiltered gixconfig::File::boolean() accessor instead of the trust-aware booleanfilter() accessor used by every other security-critical config read in the same file. When a repository is opened with reduced trust (an ownership mismatch, which maps .git/config sections to Trust::Reduced), these protection settings should not be honored from the untrusted repository-local config. Because the trust filter is skipped, an attacker who controls a repository's .git/config on a shared filesystem can set core.protectNTFS = false and/or core.protectHFS = false, disabling the .git path-confusion checks that run during checkout, index creation, merge, and tree editing. On case-insensitive filesystems this lets crafted tree entries resolve to the .git directory and overwrite hooks or…
Recommended action: Upgrade to 0.90.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
attachments: pocs.zip Submodule names coming from .gitmodules are exposed as unvalidated names and are later reused to derive the submodule git directory as: 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 repositoryexists=true for the traversed path; - open() returns a repository whose normalized commondir() 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 commondir().join("modules").join(name) with no confinement check. 3. gix/src/submodule/mod.rs uses that derived path during state…
Recommended action: Upgrade to 0.83.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 0.83.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
gixsubmodule::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 the update value came from that section. Once a submodule has been initialized (any workflow that writes submodule.<name.url to .git/config), and the attacker subsequently adds update = !cmd to .gitmodules, the guard passes while the command value falls through to the attacker-controlled file. On an identical repository state, git submodule update aborts with fatal: invalid value for 'submodule.sub.update', while gix::Submodule::update() returns…
Recommended action: Upgrade to 0.83.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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). Details Bug 1: Validation bypass in gix-validate/src/submodule.rs (lines 27-42) The name() function uses name.find(b"..") which returns only the FIRST occurrence. If the first .. is embedded in a non-traversal context, the function returns Ok without checking subsequent ../ sequences: Bypass: a..b/../../../.git/ passes because find(b"..") returns position 1 (the .. in a..b), checks name[3] == b'b', and returns Ok. The real /../../../ is never checked. Bug 2: Validation never called in production gixvalidate::submodule::name() has zero production callers (only test code). The names() iterator in gix-submodule/src/access.rs:29 explicitly documents it returns…
Recommended action: Upgrade to 0.83.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks. Details gitoxide uses the sha1smol 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: The output is as follows: The latter behaviour matches…
Recommended action: Upgrade to 0.71.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 0.63.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 0.63.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.