BREW-SNOWFLAKE-CLI-CVE-2… (GHSA-83VG-56QC-22M7)

Vulnerability from osv_homebrew – Published: 2026-10-23 09:08 – Updated: 2026-10-23 09:08 – Source website
VLAI
Summary
GitPython validates a submodule's ".git" path only after cloning into it (RCE)
Details

Summary

create_submodule(name, path, url) clones a submodule into the repo's own .git directory before it rejects the path. A path of ".git/hooks" is accepted by the pre-clone check, so the submodule is cloned straight into the live hooks directory, and a file named post-checkout in the submodule becomes an executable .git/hooks/post-checkout. On 3.2.0+ the later index check does raise ValueError, but only after the clone already wrote to disk, and it does not remove the planted hook; on 3.1.x there is no such check and the call succeeds silently. Either way the hook runs on the next git operation (e.g. checkout), giving code execution.

Details

The checkout path is validated too late, after the clone has already mutated disk. This breaks the "validate before mutation" invariant that commit 43a43cd8 ("Validate submodule checkout and metadata paths before mutation") set out to enforce.

Submodule.add() calls the permissive path check before cloning, and the strict check only reaches the ".git" alias at index time, after _clone_repo has written to disk:

git/objects/submodule/base.py (Submodule.add) 599: path = cls._to_relative_path(repo, path) # accepts ".git/hooks" 673: mrepo = cls._clone_repo(repo, url, path, name, ...) # clones into /.git/hooks 714: index.add([sm], write=True) # strict check only triggers here

git/index/base.py (IndexFile._preprocess_add_items) 732: _validate_repo_path(entry.path) # rejects ".git", too late

_to_relative_path only blocks ../absolute/out-of-tree paths; .git aliases are rejected only by _validate_repo_path, which was added in 3.2.0 (commit a75aedf3) and runs at the index boundary. The ValueError it raises at line 732 does not roll back what _clone_repo already wrote.

Version-dependent behavior: - 3.2.0 .. tip bda18e08: _validate_repo_path raises ValueError at index.add, but the hook is already on disk and is not removed (incorrect order of validation vs. clone). - 3.1.x (e.g. 3.1.59): _validate_repo_path does not exist and _to_relative_path does not reject .git; create_submodule(path=".git/hooks", ...) returns with no error at all and the hook is planted silently.

Proof of concept

Setup: evilsub/ : a git repo whose ROOT contains an executable file named post-checkout (the payload) victim/ : a git repo with at least 1 commit and a second branch, whose .git/hooks has NO sample hooks (the state of a minimal/CI checkout, or git init with an empty template dir, or GIT_TEMPLATE_DIR/init.templateDir empty)

import git, os.path as osp try: git.Repo("victim").create_submodule(name="x", path=".git/hooks", url=osp.abspath("evilsub")) except ValueError: pass # 3.2.0+: ".git" is rejected, but only AFTER the clone, so the plant already happened. # 3.1.x: no exception is raised at all; the call succeeds and still plants the hook.

victim/.git/hooks/post-checkout now exists, mode 0755, attacker-controlled, on every

affected version. Any later checkout runs it:

git -C victim checkout -> the hook runs -> code execution

Verified live: - tip bda18e08 (3.2.0 + 3 commits): create_submodule raised ValueError from git/index/base.py:732, yet .git/hooks/post-checkout was present and executable, and git checkout executed it. - 3.1.59: create_submodule returned with no error; .git/hooks/post-checkout was planted and executed by git checkout.

Impact

Arbitrary code execution. A library/app that creates a submodule from an attacker-influenced path ends up with an attacker-controlled executable in .git/hooks, which git runs on ordinary later operations. This affects any service that derives a submodule checkout path from untrusted data, e.g. one that ingests a submodule spec (name/path/url) from a user-supplied manifest or API request and feeds path into create_submodule. On 3.2.0+ the library's own validation is the thing that fails: it correctly rejects the .git path, but only after the submodule has already been cloned into place, so an app that traps the ValueError reasonably believes the unsafe path was blocked.

Preconditions (hence AC:H): (1) the app passes an attacker-influenced submodule path; (2) the target hook name is free in .git/hooks, true for minimal/CI/container checkouts and whenever init.templateDir/GIT_TEMPLATE_DIR is empty. With the default sample hooks present, git clone refuses the non-empty destination and no plant occurs.

Affected: all tested versions from 3.1.x (3.1.59) through the current tip bda18e08 (3.2.0 + 3 commits). 3.1.x plants silently; 3.2.0+ plants despite raising ValueError.


{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": null,
        "range_state": "affected",
        "resource": "gitpython",
        "resource_purl": "pkg:pypi/gitpython@3.2.0",
        "upstream_fixed_in": "3.2.1"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "snowflake-cli",
        "purl": "pkg:brew/snowflake-cli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/gitpython@3.2.0",
        "name": "gitpython",
        "resource": "gitpython",
        "strategy": "registry",
        "subject_version": "3.2.0"
      }
    ]
  },
  "details": "### Summary\n\n\n`create_submodule(name, path, url)` clones a submodule into the repo\u0027s own `.git`\ndirectory before it rejects the path. A `path` of \".git/hooks\" is accepted by the\npre-clone check, so the submodule is cloned straight into the live hooks directory,\nand a file named `post-checkout` in the submodule becomes an executable\n`.git/hooks/post-checkout`. On 3.2.0+ the later index check does raise `ValueError`,\nbut only after the clone already wrote to disk, and it does not remove the planted\nhook; on 3.1.x there is no such check and the call succeeds silently. Either way the\nhook runs on the next git operation (e.g. checkout), giving code execution.\n\n### Details\n\n\nThe checkout path is validated too late, after the clone has already mutated disk.\nThis breaks the \"validate before mutation\" invariant that commit 43a43cd8 (\"Validate\nsubmodule checkout and metadata paths before mutation\") set out to enforce.\n\nSubmodule.add() calls the permissive path check before cloning, and the strict check\nonly reaches the \".git\" alias at index time, after _clone_repo has written to disk:\n\ngit/objects/submodule/base.py (Submodule.add)\n  599: path = cls._to_relative_path(repo, path)           # accepts \".git/hooks\"\n  673: mrepo = cls._clone_repo(repo, url, path, name, ...) # clones into \u003cworktree\u003e/.git/hooks\n  714: index.add([sm], write=True)                         # strict check only triggers here\n\ngit/index/base.py (IndexFile._preprocess_add_items)\n  732: _validate_repo_path(entry.path)                     # rejects \".git\", too late\n\n_to_relative_path only blocks `..`/absolute/out-of-tree paths; `.git` aliases are\nrejected only by _validate_repo_path, which was added in 3.2.0 (commit a75aedf3) and\nruns at the index boundary. The ValueError it raises at line 732 does not roll back\nwhat _clone_repo already wrote.\n\nVersion-dependent behavior:\n- 3.2.0 .. tip bda18e08: _validate_repo_path raises ValueError at index.add, but the\n  hook is already on disk and is not removed (incorrect order of validation vs. clone).\n- 3.1.x (e.g. 3.1.59): _validate_repo_path does not exist and _to_relative_path does\n  not reject `.git`; create_submodule(path=\".git/hooks\", ...) returns with no error at\n  all and the hook is planted silently.\n\n### Proof of concept\n\n\nSetup:\n  evilsub/ : a git repo whose ROOT contains an executable file named post-checkout (the payload)\n  victim/  : a git repo with at least 1 commit and a second branch, whose .git/hooks has NO\n             sample hooks (the state of a minimal/CI checkout, or `git init` with an empty\n             template dir, or GIT_TEMPLATE_DIR/init.templateDir empty)\n\nimport git, os.path as osp\ntry:\n    git.Repo(\"victim\").create_submodule(name=\"x\", path=\".git/hooks\", url=osp.abspath(\"evilsub\"))\nexcept ValueError:\n    pass   # 3.2.0+: \".git\" is rejected, but only AFTER the clone, so the plant already happened.\n           # 3.1.x: no exception is raised at all; the call succeeds and still plants the hook.\n\n#### victim/.git/hooks/post-checkout now exists, mode 0755, attacker-controlled, on every\n#### affected version. Any later checkout runs it:\n####  git -C victim checkout \u003cother-branch\u003e   -\u003e   the hook runs   -\u003e   code execution\n\nVerified live:\n- tip bda18e08 (3.2.0 + 3 commits): create_submodule raised ValueError from\n  git/index/base.py:732, yet .git/hooks/post-checkout was present and executable, and\n  `git checkout` executed it.\n- 3.1.59: create_submodule returned with no error; .git/hooks/post-checkout was planted\n  and executed by `git checkout`.\n\n### Impact\n\nArbitrary code execution. A library/app that creates a submodule from an\nattacker-influenced `path` ends up with an attacker-controlled executable in\n`.git/hooks`, which git runs on ordinary later operations. This affects any service\nthat derives a submodule checkout path from untrusted data, e.g. one that ingests a\nsubmodule spec (name/path/url) from a user-supplied manifest or API request and feeds\n`path` into create_submodule. On 3.2.0+ the library\u0027s own validation is the thing that\nfails: it correctly rejects the `.git` path, but only after the submodule has already\nbeen cloned into place, so an app that traps the ValueError reasonably believes the\nunsafe path was blocked.\n\nPreconditions (hence AC:H): (1) the app passes an attacker-influenced submodule `path`;\n(2) the target hook name is free in `.git/hooks`, true for minimal/CI/container\ncheckouts and whenever init.templateDir/GIT_TEMPLATE_DIR is empty. With the default\nsample hooks present, `git clone` refuses the non-empty destination and no plant occurs.\n\nAffected: all tested versions from 3.1.x (3.1.59) through the current tip bda18e08\n(3.2.0 + 3 commits). 3.1.x plants silently; 3.2.0+ plants despite raising ValueError.",
  "id": "BREW-snowflake-cli-CVE-2026-114145",
  "modified": "2026-10-23T09:08:32Z",
  "published": "2026-10-23T09:08:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-83vg-56qc-22m7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-114145"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gitpython-developers/GitPython/pull/2264"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gitpython-developers/GitPython/commit/97eadb888d2f99567e3113f4e455be4ca128f697"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gitpython-developers/GitPython"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gitpython-developers/GitPython/releases/tag/3.2.1"
    }
  ],
  "schema_version": "1.7.3",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "GitPython validates a submodule\u0027s \".git\" path only after cloning into it (RCE)",
  "upstream": [
    "GHSA-83vg-56qc-22m7",
    "CVE-2026-114145"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
Events included in the timeline

Loading timeline…


    Loading…

    Loading…

    Loading…

    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.