{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/gix/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["gitoxide (\u003c= 0.52.0)","gix (\u003c 0.83.0)"],"_cs_severities":["high"],"_cs_tags":["symlink","gitoxide","gix","repository-boundary-violation"],"_cs_type":"advisory","_cs_vendors":["GitoxideLabs"],"content_html":"\u003cp\u003eA repository boundary violation vulnerability exists in gitoxide (\u0026lt;= 0.52.0) and gix (\u0026lt; 0.83.0) related to how submodule metadata is loaded. When \u003ccode\u003eRepository::submodules()\u003c/code\u003e is called, the library prefers the worktree\u0026rsquo;s \u003ccode\u003e.gitmodules\u003c/code\u003e file. The vulnerability arises because the library uses \u003ccode\u003estd::fs::read()\u003c/code\u003e to read this file, which follows symbolic links. A malicious repository can exploit this by including a symlinked \u003ccode\u003e.gitmodules\u003c/code\u003e file that points to an external location. As a result, gitoxide parses submodule configurations from an attacker-controlled file outside the repository, leading to potential injection of malicious metadata. This can mislead callers about submodule metadata, such as name, path, and URL, and influence downstream workflows related to cloning, fetching, or updating.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker creates a malicious repository.\u003c/li\u003e\n\u003cli\u003eThe repository contains a symbolic link named \u003ccode\u003e.gitmodules\u003c/code\u003e that points to a file outside the repository\u0026rsquo;s worktree controlled by the attacker.\u003c/li\u003e\n\u003cli\u003eA user clones the malicious repository using a vulnerable version of gitoxide or gix.\u003c/li\u003e\n\u003cli\u003eThe application calls \u003ccode\u003eRepository::submodules()\u003c/code\u003e to enumerate submodules.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003estd::fs::read()\u003c/code\u003e follows the symlink when reading the \u003ccode\u003e.gitmodules\u003c/code\u003e file.\u003c/li\u003e\n\u003cli\u003egitoxide parses the contents of the attacker-controlled file as submodule configuration.\u003c/li\u003e\n\u003cli\u003eThe parsed submodule data, including attacker-controlled name, path, and URL values, is exposed through the \u003ccode\u003eSubmodule\u003c/code\u003e objects.\u003c/li\u003e\n\u003cli\u003eDownstream git workflows use the injected metadata to clone, fetch, update, or enforce policies, potentially leading to unintended or malicious actions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe vulnerability allows for the injection of out-of-repository bytes into the result of \u003ccode\u003eRepository::submodules()\u003c/code\u003e. This means attackers can mislead callers about submodule metadata, such as name, path, and URL. Any downstream workflow that uses these values to decide clone, fetch, update, or policy behavior is operating on attacker-controlled data. While the report doesn\u0026rsquo;t claim direct command execution, it highlights the risk of metadata injection across the repository boundary, potentially leading to security breaches or data compromise.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cp\u003ePrioritize the following actions to mitigate this vulnerability:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to gitoxide version \u0026gt; 0.52.0 or gix version \u0026gt;= 0.83.0 to incorporate the fix that prevents following symlinks for \u003ccode\u003e.gitmodules\u003c/code\u003e (Affected Products).\u003c/li\u003e\n\u003cli\u003eImplement checks to reject symlinked \u003ccode\u003e.gitmodules\u003c/code\u003e files when loading from the worktree using \u003ccode\u003esymlink_metadata()\u003c/code\u003e or \u003ccode\u003elstat\u003c/code\u003e style checks (Reference: GHSA-pg4w-g64p-qwhj).\u003c/li\u003e\n\u003cli\u003eCanonicalize the target path of \u003ccode\u003e.gitmodules\u003c/code\u003e and verify that it resides within the repository worktree before reading (Reference: GHSA-pg4w-g64p-qwhj).\u003c/li\u003e\n\u003cli\u003eFor security-sensitive callers, prefer loading \u003ccode\u003e.gitmodules\u003c/code\u003e from the index or \u003ccode\u003eHEAD\u003c/code\u003e tree rather than following the worktree path (Reference: GHSA-pg4w-g64p-qwhj).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-05T19:26:09Z","date_published":"2026-05-05T19:26:09Z","id":"/briefs/2024-01-09-gitoxide-symlink/","summary":"A vulnerability in gix and gitoxide allows a malicious repository to use a symlinked `.gitmodules` file pointing outside the repository, leading to the parsing of arbitrary, attacker-controlled submodule configurations and potential manipulation of downstream git operations.","title":"gix and gitoxide Repository Boundary Violation via Symlinked .gitmodules","url":"https://feed.craftedsignal.io/briefs/2024-01-09-gitoxide-symlink/"}],"language":"en","title":"CraftedSignal Threat Feed — Gix","version":"https://jsonfeed.org/version/1.1"}