standardebooks

### Summary

This is a residual of GHSA-g5vv-9gxw-82hx / CVE-2026-87819. The 3.1.60 fix made `Actor._from_string` regex-free, but `parse_actor_and_date` still runs `_re_actor_epoch` on the same author/committer/tagger line one step earlier. That pattern backtracks quadratically when the trailing epoch or timezone is missing or malformed, so the same class of slow parse is still reachable in 3.1.62.

### Details

`git/objects/util.py:322`:

```python
_re_actor_epoch = re.compile(r"^.+? (.*) (\d+) ([+-]\d+).*$")
```

`.+?` and `(.*)` can both absorb the same run of spaces, and the required ` (\d+) ([+-]\d+)` tail is only checked after them. On a long line with no valid tail, the search retries every split point.

It is called from `parse_actor_and_date` (`git/objects/util.py:335`), which runs on the author and committer lines in `Commit._deserialize` (`git/objects/commit.py:917`, `:931`) and on the tagger line in `git/objects/tag.py:129`.

The published payload (letters plus an unterminated `<`) is fast on 3.1.62. Replacing the letters with spaces is not:

| author line (after `author `) | 2 KB | 8 KB | 32 KB |
|---|---|---|---|
| `'a'*n + ' <'` (advisory payload) | 0.0 ms | 0.1 ms | 0.4 ms |
| `' '*n` | 28 ms | 453 ms | 7,700 ms |
| valid line, long name (control) | 0.0 ms | 0.0 ms | 0.0 ms |

Cost grows about 16x for each 4x increase in length.

### PoC

```python
import time
from git.objects.util import parse_actor_and_date

line = "author " + " " * 32000
t = time.perf_counter()
parse_actor_and_date(line)
print(f"{time.perf_counter() - t:.1f} s")   # ~7 s on 3.1.62
```

End to end, reading `Commit.author` on a commit object whose author line is 32 KB of spaces followed by any malformed tail (no epoch, no timezone, non-numeric epoch, or bad timezone) takes about 7.2 s per access. The same line with a valid `1191999972 -0700` tail takes 1.3 ms.

Note for reproducing: `git hash-object -t commit -w` refuses such an object (`missingEmail`), so the test object was written with `--literally`. A remote can still serve one, because `fetch.fsckObjects` and `transfer.fsckObjects` default to false. This is the same delivery model as CVE-2026-87819 ("craft a commit object with a malformed author field").

### Impact

CPU exhaustion (CWE-1333) in any application that uses GitPython to read commits or tags from an untrusted repository: CI tooling, repository scanners, code-hosting integrations. Each access to `Commit.author`, `Commit.committer` or `TagObject.tagger` on a crafted object costs seconds, and a repository can contain many such objects.

### Suggested fix

Match the leading field name with `.[^ ]*` instead of `.+?`. Both stop at the first space after the first character, but `.[^ ]*` cannot overlap the following `(.*)`, so the backtracking disappears:

```python
_re_actor_epoch = re.compile(r"^.[^ ]* (.*) (\d+) ([+-]\d+).*$")
_re_only_actor = re.compile(r"^.[^ ]* (.*)$")
```

Verification on current main (73a72c9):

- Differential over 368 actor lines (real-world shapes plus edge cases): 0 differences in match groups for either regex.
- `' '*n` at 64 KB: 32,170 ms before, 0.98 ms after. Valid lines are unchanged (0.01 ms).
- The existing test suite gives the same pass/fail set with and without the change
- The new regression test, `test_parse_actor_and_date_malformed_line_is_linear`, fails on the old pattern (8.4 s) and passes with the fix (0.5 s).

The full patch (fix plus regression test) is attached below.

```diff
diff --git a/git/objects/util.py b/git/objects/util.py
index a68d701f..d8c0594d 100644
--- a/git/objects/util.py
+++ b/git/objects/util.py
@@ -319,8 +319,11 @@ def parse_date(string_date: Union[str, datetime]) -> Tuple[int, int]:
 
 
 # Precompiled regexes
-_re_actor_epoch = re.compile(r"^.+? (.*) (\d+) ([+-]\d+).*$")
-_re_only_actor = re.compile(r"^.+? (.*)$")
+# The leading field name ("author", "committer", "tagger") is matched with ``.[^ ]*`` rather than
+# ``.+?``: both stop at the first space after the first character, but ``.[^ ]*`` cannot overlap the
+# following ``(.*)``, so a line with no valid trailing epoch/offset no longer backtracks quadratically.
+_re_actor_epoch = re.compile(r"^.[^ ]* (.*) (\d+) ([+-]\d+).*$")
+_re_only_actor = re.compile(r"^.[^ ]* (.*)$")
 
 
 def parse_actor_and_date(line: str) -> Tuple[Actor, int, int]:
diff --git a/test/test_util.py b/test/test_util.py
index cf4299d5..e1631420 100644
--- a/test/test_util.py
+++ b/test/test_util.py
@@ -22,6 +22,7 @@ from git.cmd import dashify
 from git.objects.util import (
     altz_to_utctz_str,
     from_timestamp,
+    parse_actor_and_date,
     parse_date,
     tzoffset,
     utctz_to_altz,
@@ -571,6 +572,30 @@ class TestUtils(TestBase):
             Actor("name last another", "some-very-long-email@example.com"),
         )
 
+    def test_parse_actor_and_date_malformed_line_is_linear(self):
+        # A long author line whose trailing epoch/offset is missing or malformed used to make
+        # _re_actor_epoch backtrack 

Standardebooks: GitPython parse_actor_and_date() is vulnerable to quadratic backtracking on malformed identity lines…

dstack

Dstack: GitPython parse_actor_and_date() is vulnerable to quadratic backtracking on malformed identity lines…

conda-lock

Conda lock: GitPython parse_actor_and_date() is vulnerable to quadratic backtracking on malformed identity lines…

gitup

Gitup: GitPython parse_actor_and_date() is vulnerable to quadratic backtracking on malformed identity lines…

cobo-cli

Cobo cli: GitPython parse_actor_and_date() is vulnerable to quadratic backtracking on malformed identity lines…

cf2tf

Cf2tf: GitPython parse_actor_and_date() is vulnerable to quadratic backtracking on malformed identity lines…

cycode

Cycode: GitPython parse_actor_and_date() is vulnerable to quadratic backtracking on malformed identity lines…

Apm: GitPython parse_actor_and_date() is vulnerable to quadratic backtracking on malformed identity lines…

btcli

Btcli: GitPython parse_actor_and_date() is vulnerable to quadratic backtracking on malformed identity lines…

python-git

GitPython versions before 3.2.0 have a regular expression denial of service (ReDoS) vulnerability in the _re_actor_epoch pattern used during parsing of author, committer, and tagger lines. Malicious repositories with specially crafted commit or tag objects containing long space-filled lines without valid epoch or timezone can cause excessive CPU usage due to quadratic backtracking.

Python git: GitPython before 3.2.0 contains a regular expression denial of service vulnerability in the…

gitpython

GitPython

GitPython versions before 3.2.0 contain a regular expression denial of service (ReDoS) vulnerability in the _re_actor_epoch pattern used during parsing of author, committer, and tagger lines. This flaw allows attackers to cause excessive CPU consumption by serving repositories with commit or tag objects that have long space-filled lines without valid epoch or timezone information, triggering inefficient regex processing.

CVE-2026-110856: Inefficient Regular Expression Complexity in gitpython-developers GitPython

Search: CVE-2026-110856