
Cloud Vulnerability DB
A community-led vulnerabilities database
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).
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).
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).
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).
.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.gitoxide < 0.52.1 or gix < 0.82.0) to clone or open the malicious repository and calls Repository::submodules()..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.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)..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./etc/passwd, /etc/shadow, configuration files) coinciding with repository clone or submodule enumeration operations.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).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).
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).
Fix availability across major Linux distributions and their releases.
Source: This report was generated using AI
Free Vulnerability Assessment
Evaluate your cloud security practices across 9 security domains to benchmark your risk level and identify gaps in your defenses.
Get a personalized demo
"Best User Experience I have ever seen, provides full visibility to cloud workloads."
"Wiz provides a single pane of glass to see what is going on in our cloud environments."
"We know that if Wiz identifies something as critical, it actually is."