CVE-2026-118475 is an out-of-bounds read vulnerability in Eye of GNOME on Red Hat Enterprise Linux 7. It occurs when parsing a specially crafted PNG image with malformed color profile metadata, leading to reading beyond allocated buffer boundaries. This can cause the application to crash (Denial of Service) or potentially expose sensitive memory contents. Exploitation requires user interaction to open a malicious image in an interactive desktop session, limiting impact to the local user's permissions.
CVE-2026-112922 is a vulnerability in Ghostscript affecting Red Hat Enterprise Linux 10. It involves an out-of-bounds read triggered by processing specially crafted PDF or PostScript documents with malicious mesh shading data. Exploitation can cause application crashes leading to Denial of Service (DoS) or limited information disclosure. The vulnerability requires local user interaction to exploit and has a low severity rating. Currently, no mitigation or patch meeting Red Hat's criteria is available.
A security vulnerability (CVE-2026-8932) in libcurl, part of the curl packages provided by Red Hat, allows a security feature bypass due to improper mutual TLS (mTLS) connection reuse. This issue affects Red Hat Enterprise Linux 9 and related variants. The vulnerability has been rated as moderate in severity by Red Hat Product Security. An update addressing this issue is available in Red Hat Enterprise Linux 9.8 and Extended Update Support 9.8 packages.
CVE-2026-15466 is a use-after-free vulnerability in Imagination Technologies Graphics DDK. It arises from a race condition in the destruction path of hardware performance counters buffer, where improper GPU system calls by non-privileged users can cause the reference counter to be decremented non-atomically. This allows other code paths to access freed kernel heap memory, leading to potential read and/or write use-after-free conditions.
CVE-2026-91920 is a vulnerability in the ChunkReader component of the Undertow web server used by Red Hat build of Apache Camel for Spring Boot 4. The flaw arises from an incomplete bounds check on chunk sizes in HTTP chunked transfer encoding, allowing a crafted 15-digit chunk size to overflow internal state flags. This can cause premature termination of the request body and interpretation of remaining data as a separate smuggled HTTP request. Exploitation requires precise TCP segmentation control. The vulnerability is rated medium severity with a CVSS score of 6.5.
CVE-2026-107238 is a high-severity vulnerability in the Veeam Management Pack for Microsoft System Center Collector service that allows an authenticated domain user to execute code remotely with LocalSystem privileges on affected servers. This vulnerability enables privilege escalation to the highest system level, potentially compromising the entire server. No specific affected versions or patch information is provided in the available data.
CVE-2026-92744 is a high-severity vulnerability in a privilege manager agent that under certain conditions allows a remote unauthenticated attacker to execute arbitrary code with LocalSystem privileges. The vulnerability has a CVSS 4.0 base score of 8.7, indicating significant impact. No affected versions or patch information are provided, and no known exploits are reported in the wild.
This vulnerability allows a member of the Veeam Virtualization Extensions Users group to execute remote code on servers running the Veeam Management Pack for Microsoft System Center Collector service. It is identified as CVE-2026-107239 with a high severity score of 8.8. The vulnerability involves a path traversal issue (CWE-23) that could lead to remote code execution. No affected versions or patch information are provided, and there are no known exploits in the wild at this time.
An authenticated, low-privileged Nessus user on Linux with scan-creation rights can read arbitrary text files on the scanner host by running a custom Unix compliance audit. This allows reading files with the privileges of the nessusd process without requiring higher privileges or user interaction.
Spreadsheet::XLSX versions before 0.19 for Perl contain a vulnerability that allows arbitrary code execution. The flaw arises from the use of string eval on number format conditions in ExcelFmt during workbook parsing. An attacker can craft a malicious XLSX file with a specially formatted number condition to execute arbitrary Perl code when the file is processed.
Tornado's RedirectHandler in versions >=2.2.0 <2.2.2_7 allows open redirect vulnerabilities when URL templates include substitutions that can alter the scheme or host of the redirect target. This can enable attackers to craft URLs that redirect users to arbitrary external sites, facilitating phishing attacks. The issue is fixed in version 2.2.2_7 by rejecting substitutions that change the scheme or host.
Tornado HTTP servers have a vulnerability in their header parser that causes quadratic CPU usage when parsing HTTP headers with obsolete line folding (line continuation with leading whitespace). An unauthenticated attacker can exploit this by sending specially crafted requests with many folded header lines, causing the server's event loop to block and degrade availability. The issue affects all Tornado HTTP servers before version 6.6. The vulnerability is fixed in Tornado 6.6 by removing support for obsolete line folding and rejecting header lines starting with whitespace.
Tornado HTTP servers are vulnerable to event loop blocking and excessive memory use when processing HTTP/1.1 chunked transfer encoding bodies composed of many small chunks. An attacker can send a request body with millions of 1-byte chunks, causing the event loop to block for extended periods (up to a minute for ~100 MB bodies) and consuming significantly more memory than the actual body size. This affects all Tornado HTTP servers that read request bodies without early rejection and also affects the SimpleAsyncHTTPClient when reading responses. The issue is fixed in Tornado 6.6 with changes to yield to the event loop periodically and optimize chunk handling.
A vulnerability in Apple Xcode allows an app to read arbitrary files due to improper handling of symlinks. This issue is resolved in Xcode version 27.2 with improved symlink handling.
A vulnerability in Apple Xcode prior to version 27.2 could allow an app to access sensitive user data due to an authorization issue. This flaw was addressed by improved state management and fixed in Xcode 27.2.
GitPython's Submodule.move() API does not properly validate symbolic links in the destination path, allowing an attacker-controlled symlink to redirect submodule moves outside the parent repository worktree. This can cause the submodule checkout to be moved to an unintended external directory, corrupting the parent repository's index and configuration. The vulnerability requires an attacker to supply a malicious Git repository with a symlinked path and the application to call Submodule.move() on a path beneath that symlink. No code execution or confidentiality impact is demonstrated, but the integrity of the repository is compromised.
GitPython versions up to 3.1.62 contain a vulnerability in the Head.checkout() method that allows an attacker to read arbitrary files on the system by controlling the branch name. This occurs because the branch name, passed as a positional argument, is not properly sanitized and can inject unsafe git checkout options such as --pathspec-from-file, leading to disclosure of sensitive files like /etc/passwd. The vulnerability arises from an incomplete fix of prior advisories that only guarded keyword arguments but missed positional argument checks in Head.checkout().
GitPython's Remote.pull() method improperly handles the positional refspec argument, allowing an attacker to inject a malicious --upload-pack option that bypasses the unsafe-option guard. This leads to arbitrary command execution with the privileges of the calling process when using local-path or SSH transports. The vulnerability affects Snakemake versions from 7.20.0 up to but not including 9.27.0_1. A fix is available in version 9.27.0_1.
### Summary
GitPython has spent 2022-2026 rolling out two reusable guards method-by-method: `Git.check_unsafe_protocols(url)` (raises `UnsafeProtocolError` for `<transport>::` remote-helper URLs - CVE-2022-24439) and `Git.check_unsafe_options(...)` (raises `UnsafeOptionError` for denylisted option spellings - CVE-2023-40267, CVE-2026-42215, CVE-2026-67323). Three wrapper methods that build a `git` argv from caller-controlled values still have **neither**:
1. **`Git.ls_remote`** (git/cmd.py:1128-1143) - checks options (:1139-1141) but forwards the URL positional unchecked; no `allow_unsafe_protocols` parameter exists. The same URL through `clone_from` raises `UnsafeProtocolError`.
2. **`Repo.merge_base`** (git/repo/base.py:895-936) - forwards `**kwargs`/`*rev` to `self.git.merge_base` with no guard; guarded sibling `iter_commits` sits 12 lines up. Its exception handler additionally swallows every non-128 `GitCommandError` into `[]`, masking the injection.
3. **`IndexFile.move`** (git/index/base.py:1092-1168) - forwards `**kwargs` to `git mv` twice (:1147, :1167); guarded sibling `remove()` is 23 lines above.
Verified unfixed on `main @ a54d159` (2026-09-21), post-dating latest release 3.1.62 (2026-09-07) - all three sites re-verified today.
### Impact
**Site 1 (`ls_remote`)** - RCE conditional on the victim git transport policy. The common 'probe first, then clone' pattern (`Git(...).ls_remote(attacker_url)`) with an `ext::sh -c ...` URL executes arbitrary commands when the victim git permits the ext transport: dynamically verified with `protocol.ext.allow=always` (marker executed). git >= 2.38.1 stock config refuses the transport (`fatal: transport 'ext' not allowed`, rc 128) - GitPython adds no defense-in-depth and surfaces a bare `GitCommandError`. Environments on git < 2.38.1 are exposed with stock config - the exact population CVE-2022-24439 was scored against.
**Sites 2/3** - latent argument-injection surface: caller kwargs flow 1:1 into the `git` argv before operands and `--` (cmd.py:1850 `opt_args + ext_args`), and `execute_kwargs` (incl. `shell=True`/`env` - the CVE-2023-40267 Windows mechanism) passes through unguarded. Today `git merge-base`/`git mv` expose no exec option, so we claim the missing-guard class (vendor-settled by CVE-2026-67323, which bundled archive/ls_remote/iter_commits/blame in one advisory), not direct RCE.
### Dynamic verification (today; GitPython main @ a54d159, git 2.55.0, Linux)
| # | Call | Result |
|---|---|---|
| T1 | `repo.git.ls_remote('ext::/tmp/gp_touch.sh')`, stock config | git refuses (rc 128); **no `UnsafeProtocolError` from GitPython** |
| T1b | same + victim config `protocol.ext.allow=always` | **marker created - arbitrary command executed** |
| T2 | `repo.git.ls_remote('.', upload_pack=...)` | blocked by cmd.py:1141 (options-side fixed - protocol-side is the residual gap) |
| T3 | `repo.merge_base('main','side', upload_pack=...)` | **not blocked**; argv `git merge-base --upload-pack=... main side`; rc 129 silently converted to `[]` |
| T4 | `repo.index.move(['f1','f2'], output=...)` | **not blocked**; option reaches `git mv` (rc 129) |
### Coverage matrix (main @ a54d159)
`check_unsafe_protocols`: 7 call sites (`_clone`, `archive`, `set_url`, `create`, `fetch`, `pull`, `push`) - none on `ls_remote`.
`check_unsafe_options`: 24 call sites incl. `ls_remote`, `iter_commits`, `IndexFile.remove` - absent on `merge_base` and `move`.
### Precedents (same repo, same guard family)
- **CVE-2022-24439 / GHSA-hcpj-qp55-gfph** (critical): `check_unsafe_protocols` on the clone path - Site 1 is the same `ext::` primitive on a sibling API.
- **CVE-2023-40267 / GHSA-pr76-5cm5-w9cj** (critical, 'incomplete fix for CVE-2022-24439'): `check_unsafe_options` - unguarded kwargs to argv treated as RCE (`shell=True` on Windows).
- **CVE-2026-42215 / GHSA-rpm5-65cw-6hj4** (high, fixed 3.1.47): underscored-spelling bypass - rollout still active in 2026.
- **CVE-2026-67323 / GHSA-956x-8gvw-wg5v** (high, 8.4, fixed 3.1.51): added `check_unsafe_options` to `archive`/`ls_remote`/`iter_commits`/`blame`; its PoC is literally `repo.git.ls_remote('.', upload_pack=...)`. Establishes that a wrapper missing the check is itself a vulnerability. This report is the residual gap of that rollout: `ls_remote` got options but not protocols; `merge_base`/`move` got neither.
### Recommended fix (existing helpers, 1-3 lines per site)
1. `Git.ls_remote`: `if not allow_unsafe_protocols: self.check_unsafe_protocols(args[0])` + new `allow_unsafe_protocols: bool = False` (the `_clone` pattern, base.py:1536-1538).
2. `Repo.merge_base`: `check_unsafe_options(Git._option_candidates(list(rev), kwargs), unsafe_options=self.unsafe_git_revision_options)` (the `iter_commits` pattern); stop masking non-128 statuses.
3. `IndexFile.move`: the `remove()` pattern with `unsafe_git_pathspec_from_file_options`.
One advisory, three affected methods, severity anchored on Site 1 - mirroring CVE-2026-67323's bundling.
### 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