CVE-2026-82252
CBL Mariner vulnerability analysis and mitigation

Overview

CVE-2026-82252 is a symlink-following vulnerability in gitoxide (the Rust-based Git implementation by GitoxideLabs) that allows attackers to inject out-of-repository content into submodule metadata. When Repository::submodules() loads the worktree .gitmodules file, it uses std::fs::read() without checking whether the path is a symlink, enabling a malicious repository to redirect parsing to arbitrary files outside the repository tree. Affected versions are gitoxide (the gitoxide crate) before 0.52.1 and the gix crate before 0.82.0. The vulnerability was published on August 28, 2026, with a CVSS v3.1 score of 7.5 (High) and a CVSS v4.0 score of 8.7 (High) (GitHub Advisory, GHSA-pg4w-g64p-qwhj).

Technical details

The root cause is classified as CWE-59 (Improper Link Resolution Before File Access / 'Link Following'). The vulnerable code path in gix/src/repository/submodule.rs reads the worktree .gitmodules path using std::fs::read(), which transparently follows symbolic links without verifying that the resolved target remains within the repository worktree boundary. An attacker crafts a malicious repository where .gitmodules is a symlink pointing to an arbitrary file outside the repository (e.g., /etc/passwd or any attacker-chosen path), and when a victim clones and processes this repository with gitoxide, the library parses the external file as submodule configuration. The resulting Submodule objects expose attacker-controlled name, path, and url values to any downstream caller of the high-level submodule API. A proof-of-concept (pocs.zip) was included with the original advisory (GHSA-pg4w-g64p-qwhj).

Impact

Successful exploitation results in a repository-boundary violation where arbitrary files readable by the process running gitoxide can have their contents parsed and exposed as submodule metadata (name, path, and URL fields). This constitutes a high-confidentiality-impact information disclosure: sensitive files such as configuration files, credentials, or private keys accessible on the host filesystem could be exfiltrated if a downstream workflow logs, transmits, or acts on the parsed submodule metadata. There is no direct integrity or availability impact from this code path alone, but any downstream system that uses the attacker-controlled submodule url or path values to drive clone, fetch, or policy decisions is operating on attacker-supplied data, potentially enabling further exploitation (GHSA-pg4w-g64p-qwhj, GitHub Advisory).

Exploitability

The vulnerability is exploitable remotely with no authentication and no user interaction required beyond a victim processing a malicious repository, making it automatable (confirmed by NVD SSVC). A proof-of-concept was attached to the original security advisory (pocs.zip), though no public weaponized exploit or active in-the-wild exploitation has been reported as of the advisory date. The EPSS score is approximately 0.387% (32nd percentile), indicating a relatively low but non-negligible probability of exploitation in the near term. The CVE is not currently listed in the CISA Known Exploited Vulnerabilities catalog (GitHub Advisory, GHSA-pg4w-g64p-qwhj).

Exploitation steps

  1. Prepare a malicious repository: Create a Git repository and, instead of a normal .gitmodules file, create a symbolic link named .gitmodules pointing to a target file outside the repository (e.g., ln -s /etc/passwd .gitmodules). Commit this symlink to the repository.
  2. Host the malicious repository: Make the repository available via a Git hosting service, HTTP server, or local path accessible to the victim.
  3. Victim clones or processes the repository: The victim uses a gitoxide-based tool or application (using gitoxide < 0.52.1 or gix < 0.82.0) to clone or open the malicious repository and calls Repository::submodules().
  4. Symlink is followed: gitoxide resolves the worktree .gitmodules path and calls std::fs::read(), which transparently follows the symlink and reads the external file (e.g., /etc/passwd) as if it were the repository's submodule configuration.
  5. Attacker-controlled data is exposed: The parsed Submodule objects expose the contents of the external file as name, path, and url fields. Any downstream logging, API response, or workflow that surfaces these values leaks the file contents to the attacker (GHSA-pg4w-g64p-qwhj).

Indicators of compromise

  • File System: Presence of a .gitmodules entry in a cloned repository that is a symbolic link (detectable via ls -la or git ls-files --stage | grep .gitmodules showing mode 120000) pointing to a path outside the repository worktree.
  • File System: Unexpected access timestamps on sensitive system files (e.g., /etc/passwd, /etc/shadow, configuration files) coinciding with repository clone or submodule enumeration operations.
  • Logs: Application or audit logs showing gitoxide-based processes reading files outside expected repository directories, particularly system configuration files or credential stores.
  • Process: Rust-based Git tooling processes (gix, gitoxide) accessing file paths that do not reside under the repository's working directory, observable via strace, auditd, or similar syscall monitoring tools (GHSA-pg4w-g64p-qwhj).

Mitigation and workarounds

Upgrade the gitoxide crate to version 0.52.1 or later, and the gix crate to version 0.82.0 or later, which resolve the issue by preventing silent symlink following for the worktree .gitmodules path. As a workaround where patching is not immediately possible, restrict which repositories are cloned or processed by gitoxide-based tooling, and avoid processing untrusted repositories. Security-sensitive callers should prefer loading .gitmodules from the index or HEAD tree rather than the worktree path. Additionally, implement access controls (e.g., filesystem permissions, sandboxing) to limit the files readable by the gitoxide process (GHSA-pg4w-g64p-qwhj, GitHub Advisory).

Community reactions

The vulnerability was reported by researcher N0zoM1z0 and published by the gitoxide maintainer (Byron) via GitHub Security Advisories on April 25, 2026, with the CVE assigned and published on August 28, 2026. A Mastodon post from @thehackerwire noted the disclosure shortly after publication. No significant broader media coverage or notable researcher commentary beyond the original advisory has been identified (GHSA-pg4w-g64p-qwhj).

Additional resources

Linux Distribution fix status

Fix availability across major Linux distributions and their releases.

Debian

Fixed

sid

rust-gix: 0.83.0-1

Fixed

trixie

rust-gix

Affected

Ubuntu

Unknown

devel

rust-gix

Unknown

resolute

rust-gix

Unknown

resolute (esm-apps)

rust-gix

Unknown

SourceThis report was generated using AI

Related CBL Mariner vulnerabilities:

CVE ID

Severity

Score

Technologies

Component name

CISA KEV exploit

Has fix

Published date

CVE-2026-6554MEDIUM5.5
  • CBL Mariner logoCBL Mariner
  • libpcap.src
NoYesSep 05, 2026
CVE-2026-6244MEDIUM5.5
  • CBL Mariner logoCBL Mariner
  • libpcap
NoYesSep 05, 2026
CVE-2026-31912MEDIUM5.5
  • CBL Mariner logoCBL Mariner
  • libpcap-devel
NoYesSep 05, 2026
CVE-2026-31911MEDIUM5.5
  • CBL Mariner logoCBL Mariner
  • libpcap
NoYesSep 05, 2026
CVE-2026-18313MEDIUM4.3
  • CBL Mariner logoCBL Mariner
  • libpcap
NoYesSep 05, 2026

Free Vulnerability Assessment

Benchmark your Cloud Security Posture

Evaluate your cloud security practices across 9 security domains to benchmark your risk level and identify gaps in your defenses.

Request assessment

Get a personalized demo

Ready to see Wiz in action?

"Best User Experience I have ever seen, provides full visibility to cloud workloads."
David EstlickCISO
"Wiz provides a single pane of glass to see what is going on in our cloud environments."
Adam FletcherChief Security Officer
"We know that if Wiz identifies something as critical, it actually is."
Greg PoniatowskiHead of Threat and Vulnerability Management