{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/gitoxide/","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/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["gix-pack (\u003c= 0.68.0)"],"_cs_severities":["medium"],"_cs_tags":["denial-of-service","git","gitoxide","gix-pack"],"_cs_type":"advisory","_cs_vendors":["rust"],"content_html":"\u003cp\u003eThe \u003ccode\u003egix-pack\u003c/code\u003e library, a Rust implementation of Git packfile handling, contains multiple denial-of-service (DoS) vulnerabilities. Specifically, unchecked array indexing in delta processing can lead to panics, and uncapped memory allocation based on attacker-controlled size headers allows for out-of-memory (OOM) attacks. These vulnerabilities are triggered when processing malicious pack data during clone or fetch operations.  The affected versions are \u003ccode\u003egix-pack\u003c/code\u003e \u0026lt;= 0.68.0. This poses a risk to any application built on gitoxide that clones or fetches from an untrusted remote, including the \u003ccode\u003egix\u003c/code\u003e CLI, applications using the \u003ccode\u003egix\u003c/code\u003e crate, and CI/CD systems cloning repositories using gitoxide. A crafted pack entry claiming a multi-terabyte size triggers an immediate process kill, which constitutes a single-packet process kill with no recovery.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker crafts a malicious Git packfile containing either truncated delta data or an entry with an extremely large \u003ccode\u003edecompressed_size\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eA user or automated system initiates a \u003ccode\u003egit clone\u003c/code\u003e or \u003ccode\u003egit fetch\u003c/code\u003e operation from a repository controlled by the attacker.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003egix-pack\u003c/code\u003e library attempts to parse the crafted packfile.\u003c/li\u003e\n\u003cli\u003eIf the packfile contains truncated delta data, the \u003ccode\u003eapply()\u003c/code\u003e function in \u003ccode\u003egix-pack/src/data/delta.rs\u003c/code\u003e attempts to access array indices beyond the bounds of the data buffer, leading to a panic. Alternatively, the \u003ccode\u003eparse_header_info()\u003c/code\u003e function in \u003ccode\u003egix-pack/src/data/entry/decode.rs\u003c/code\u003e can also panic due to unchecked indexing.\u003c/li\u003e\n\u003cli\u003eIf the packfile contains an entry with an extremely large \u003ccode\u003edecompressed_size\u003c/code\u003e, the library attempts to allocate a large buffer using \u003ccode\u003eVec::with_capacity(size as usize)\u003c/code\u003e in \u003ccode\u003ebytes_to_entries.rs\u003c/code\u003e or \u003ccode\u003eVec::resize()\u003c/code\u003e in \u003ccode\u003eresolve.rs\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe allocation of the excessively large buffer exhausts available memory, triggering an out-of-memory (OOM) condition.\u003c/li\u003e\n\u003cli\u003eThe operating system terminates the process to prevent further memory exhaustion.\u003c/li\u003e\n\u003cli\u003eThe application using \u003ccode\u003egix-pack\u003c/code\u003e crashes, resulting in a denial-of-service.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of these vulnerabilities leads to a denial-of-service (DoS) condition. For the panic vulnerability, a small amount of crafted data causes an immediate process abort. For the OOM vulnerability, a single crafted pack entry header causes the process to attempt a multi-terabyte allocation, leading to process termination by the operating system. This can affect various applications and systems, including the \u003ccode\u003egix\u003c/code\u003e CLI, applications using the \u003ccode\u003egix\u003c/code\u003e crate, and CI/CD systems, potentially disrupting software development workflows. The OOM vector represents a severe risk, as it is a single-packet process kill with no recovery.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to a patched version of \u003ccode\u003egix-pack\u003c/code\u003e when available.\u003c/li\u003e\n\u003cli\u003eImplement input validation on packfile data before processing to mitigate the OOM vulnerability. Specifically, implement a configurable maximum object size and validate claimed sizes against it before allocation, as suggested in the advisory.\u003c/li\u003e\n\u003cli\u003eMonitor for process crashes or OOM events related to applications using \u003ccode\u003egix-pack\u003c/code\u003e. Deploy the Sigma rule \u003ccode\u003eDetect Gix-Pack Uncapped Memory Allocation\u003c/code\u003e to identify potential OOM attacks.\u003c/li\u003e\n\u003cli\u003eConsider blocking or filtering network traffic from untrusted Git repositories to prevent malicious packfiles from reaching vulnerable systems.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-05T19:24:15Z","date_published":"2026-05-05T19:24:15Z","id":"/briefs/2024-01-09-gix-pack-dos/","summary":"Multiple denial-of-service vulnerabilities exist in `gix-pack`; crafted delta data can cause unchecked array indexing, leading to panics, and uncapped attacker-controlled size headers enable out-of-memory process kills, triggered by malicious pack data during clone/fetch operations.","title":"gix-pack Denial-of-Service Vulnerabilities","url":"https://feed.craftedsignal.io/briefs/2024-01-09-gix-pack-dos/"},{"_cs_actors":[],"_cs_cves":[{"cvss":7.8,"id":"CVE-2019-19604"}],"_cs_exploited":false,"_cs_products":["gix"],"_cs_severities":["high"],"_cs_tags":["code-vulnerability","remote-code-execution","gitoxide"],"_cs_type":"advisory","_cs_vendors":["GitoxideLabs"],"content_html":"\u003cp\u003eA vulnerability exists in gitoxide\u0026rsquo;s \u003ccode\u003egix_submodule::File::update()\u003c/code\u003e function, specifically in versions 0.31.0 to 0.82.0, that allows for arbitrary command execution. The vulnerability arises from an insufficient check on the origin of the \u003ccode\u003eupdate\u003c/code\u003e command specified in a \u003ccode\u003e.gitmodules\u003c/code\u003e file.  An attacker can exploit this by pushing a new commit with a malicious \u003ccode\u003eupdate\u003c/code\u003e command in \u003ccode\u003e.gitmodules\u003c/code\u003e after the victim initializes the submodule.  This bypasses the intended security guard, leading to potential remote command execution in downstream code that relies on \u003ccode\u003eSubmodule::update()\u003c/code\u003e and trusts the safety of \u003ccode\u003eUpdate::Command(_)\u003c/code\u003e. This issue is similar to CVE-2019-19604, highlighting the risk of unchecked commands in submodule configurations.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker creates a repository with a benign \u003ccode\u003e.gitmodules\u003c/code\u003e file, containing no \u003ccode\u003eupdate\u003c/code\u003e key.\u003c/li\u003e\n\u003cli\u003eA victim clones the attacker\u0026rsquo;s repository and runs \u003ccode\u003egit submodule init\u003c/code\u003e, which populates the \u003ccode\u003e.git/config\u003c/code\u003e file with submodule information (URL, active status), but not the \u003ccode\u003eupdate\u003c/code\u003e key.\u003c/li\u003e\n\u003cli\u003eThe attacker pushes a new commit to the repository, adding a malicious \u003ccode\u003eupdate = !\u0026lt;command\u0026gt;\u003c/code\u003e line to the \u003ccode\u003e.gitmodules\u003c/code\u003e file (e.g., \u003ccode\u003eupdate = !touch /tmp/pwned\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe victim runs \u003ccode\u003egit pull\u003c/code\u003e to update their local repository, incorporating the attacker\u0026rsquo;s modified \u003ccode\u003e.gitmodules\u003c/code\u003e file. The \u003ccode\u003e.git/config\u003c/code\u003e file remains unchanged.\u003c/li\u003e\n\u003cli\u003eA gitoxide-based application calls \u003ccode\u003eSubmodule::update()\u003c/code\u003e to determine the submodule update strategy.\u003c/li\u003e\n\u003cli\u003eThe vulnerable \u003ccode\u003egix_submodule::File::update\u003c/code\u003e function is called, which incorrectly validates the source of the \u003ccode\u003eupdate\u003c/code\u003e command.\u003c/li\u003e\n\u003cli\u003eThe function checks that a submodule section with the same name exists in a non-.gitmodules source, but does not verify if the update value comes from that section, bypassing the intended security guard.\u003c/li\u003e\n\u003cli\u003eThe attacker-controlled shell command from the \u003ccode\u003e.gitmodules\u003c/code\u003e file is executed, leading to arbitrary command execution.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe vulnerability allows an attacker to execute arbitrary commands on a system running gitoxide-based applications that utilize submodules. This could lead to complete system compromise, data exfiltration, or denial of service. Any tool, IDE plugin, or CI integration building submodule-update functionality on top of \u003ccode\u003egix\u003c/code\u003e within the affected version range inherits this vulnerability.  Successful exploitation depends on the vulnerable application\u0026rsquo;s trust in the output of \u003ccode\u003eSubmodule::update()\u003c/code\u003e which determines the update strategy.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to \u003ccode\u003egix\u003c/code\u003e version 0.83.0 or later to patch the vulnerability (\u003ca href=\"https://github.com/advisories/GHSA-f26g-jm89-4g65)\"\u003ehttps://github.com/advisories/GHSA-f26g-jm89-4g65)\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eImplement additional validation and sanitization of submodule configurations, especially when handling \u003ccode\u003eUpdate::Command(_)\u003c/code\u003e from \u003ccode\u003eSubmodule::update()\u003c/code\u003e, to prevent unintended command execution.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule below to detect potential exploitation attempts by monitoring for the execution of unexpected commands based on submodule configuration.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T18:00:00Z","date_published":"2024-01-09T18:00:00Z","id":"/briefs/2024-01-09-gitoxide-rce/","summary":"A vulnerability in gitoxide's `gix_submodule::File::update()` allows arbitrary command execution via a crafted `.gitmodules` file by incorrectly validating the source of the `update` command, enabling an attacker to inject malicious commands after a submodule has been initialized.","title":"gitoxide Arbitrary Command Execution via .gitmodules Bypass","url":"https://feed.craftedsignal.io/briefs/2024-01-09-gitoxide-rce/"}],"language":"en","title":"CraftedSignal Threat Feed — Gitoxide","version":"https://jsonfeed.org/version/1.1"}