GitPython before 3.1.62 does not validate the `path` field read from an untrusted .gitmodules file when updating submodules. While a prior fix (GHSA-hmq2-w58f-27jc) added Submodule._validated_name() to constrain the `name` field, and GitPython's own containment guard Submodule._to_relative_path() is applied in add() and move(), Submodule.update() derives the absolute checkout location from the raw `path` value without that guard. A .gitmodules entry containing directory traversal components (e.g., path = ../../../tmp/escaped) can therefore cause directories to be created via os.makedirs() outside the repository working tree, populated from the submodule URL on the clone path, and removed via shutil.rmtree() when force_remove is used. Exploitation requires an application flow that updates submodules at a non-HEAD commit (such as a historical-commit API); the common clone-then-update flow re-derives the path from a canonical tree lookup and is not affected. The issue is fixed in GitPython 3.1.62.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - GitPython before 3.1.62 does not validate the `path` field read from an untrusted .gitmodules file when
    updating submodules. While a prior fix (GHSA-hmq2-w58f-27jc) added Submodule._validated_name() to
    constrain the `name` field, and GitPython's own containment guard Submodule._to_relative_path() is applied
    in add() and move(), Submodule.update() derives the absolute checkout location from the raw `path` value
    without that guard. A .gitmodules entry containing directory traversal components (e.g., path =
    ../../../tmp/escaped) can therefore cause directories to be created via os.makedirs() outside the
    repository working tree, populated from the submodule URL on the clone path, and removed via
    shutil.rmtree() when force_remove is used. Exploitation requires an application flow that updates
    submodules at a non-HEAD commit (such as a historical-commit API); the common clone-then-update flow re-
    derives the path from a canonical tree lookup and is not affected. The issue is fixed in GitPython 3.1.62.
    (CVE-2026-100689)

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - GitPython before 3.1.62 does not validate the `path` field read from an untrusted .gitmodules file when     updating submodules. While a prior fix (GHSA-hmq2-w58f-27jc) added Submodule._validated_name() to     constrain the `name` field, and GitPython's own containment guard Submodule._to_relative_path() is applied     in add() and move(), Submodule.update() derives the absolute checkout location from the raw `path` value     without that guard. A .gitmodules entry containing directory traversal components (e.g., path =     ../../../tmp/escaped) can therefore cause directories to be created via os.makedirs() outside the     repository working tree, populated from the submodule URL on the clone path, and removed via     shutil.rmtree() when force_remove is used. Exploitation requires an application flow that updates     submodules at a non-HEAD commit (such as a historical-commit API); the common clone-then-update flow re-     derives the path from a canonical tree lookup and is not affected. The issue is fixed in GitPython 3.1.62.
    (CVE-2026-100689)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
474837	Echo: python-git: security update to 3.1.62	Tenable Cloud Security	Echo Local Security Checks	Local	high
474837	Echo: python-git: security update to 3.1.62	Tenable Self-Hosted Container Security	Echo Local Security Checks	Local	high
350791	Linux Distros Unpatched Vulnerability : CVE-2026-100689	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2026-100689

high

Tenable Plugins

high

high

high