Threats Tagged 'cve-2026-73620'

Red Hat Ansible Automation Platform provides an enterprise framework for building, deploying and managing IT automation at scale. IT Managers can provide top-down guidelines on how automation is applied to individual teams, while automation developers retain the freedom to write tasks that leverage existing knowledge without the overhead. Ansible Automation Platform makes it possible for users across an organization to share, vet, and manage automation content by means of a simple, powerful, and agentless language. For details about this release, refer to the release notes listed in the References section.

Red Hat Lightspeed in Satellite analyzes system health and configuration by applying predefined rules to a small set of local data, such as installed packages, running services, and configuration settings.

Red Hat Lightspeed in Satellite analyzes system health and configuration by applying predefined rules to a small set of local data, such as installed packages, running services, and configuration settings.

Red Hat Satellite is a system management solution that allows organizations to configure and maintain their systems without the necessity to provide public Internet access to their servers or other client systems. It performs provisioning and configuration management of predefined standard operating environments. Security Fix(es): * ansible-core: argument injection in ansible-galaxy role install leads to arbitrary code execution (CVE-2026-11332) * ansible-core: argument injection in ansible-galaxy collection install via git clone (incomplete fix for CVE-2026-11332) (CVE-2026-16493) * openvox-server: jackson-databind: Arbitrary code execution via PolymorphicTypeValidator bypass (CVE-2026-54512) * puppetserver: jackson-databind: Arbitrary code execution via PolymorphicTypeValidator bypass (CVE-2026-54512) * rubygem-jwt: ruby-jwt: Authentication bypass due to empty key in HMAC verification (CVE-2026-45363) * python-aiohttp: AIOHTTP: Denial of Service via malformed HTTP responses (CVE-2026-69244) * python-aiohttp: AIOHTTP: HTTP Request Smuggling via WebSocket Upgrade (CVE-2026-69243) * python-aiohttp: AIOHTTP: Arbitrary code execution via untrusted input to CookieJar.load() (CVE-2026-34993) * openvox-server: jackson-core: Denial of Service via incomplete fix in async JSON parser (CVE-2026-68494) * openvox-server: Eclipse Jetty: Information disclosure due to retained HTTP/1.1 trailers across connections (CVE-2026-10051) * python-gitpython: GitPython: Arbitrary File Overwrite via improper git option validation (CVE-2026-73624) * python-gitpython: GitPython: Remote Code Execution via kwarg value smuggling (CVE-2026-73625) * python-gitpython: GitPython: Information disclosure via environment variable expansion in URL handling (CVE-2026-73622) * python-gitpython: GitPython: Remote Code Execution via malicious Git template (CVE-2026-73623) * python-gitpython: GitPython: Arbitrary file overwrite and read via unsafe git option forwarding (CVE-2026-73620) * python-gitpython: GitPython: Arbitrary code execution via improper validation of clone options (CVE-2026-42284) * python3.12-gitpython: GitPython: Arbitrary code execution via improper validation of clone options (CVE-2026-42284) * python-gitpython: GitPython: Arbitrary command execution due to bypass of dangerous Git option checks (CVE-2026-42215) * python3.12-gitpython: GitPython: Arbitrary command execution due to bypass of dangerous Git option checks (CVE-2026-42215) * python-gitpython: GitPython: Arbitrary code execution via injected newlines in Git configuration (CVE-2026-44244) * python3.12-gitpython: GitPython: Arbitrary code execution via injected newlines in Git configuration (CVE-2026-44244) * python-gitpython: GitPython: Arbitrary file creation via path traversal in .gitmodules submodule names (CVE-2026-76222) * python3.12-gitpython: GitPython: Arbitrary file creation via path traversal in .gitmodules submodule names (CVE-2026-76222) * python-gitpython: GitPython: Remote Code Execution via malicious Git hooks (CVE-2026-76218) * python3.12-gitpython: GitPython: Remote Code Execution via malicious Git hooks (CVE-2026-76218) * python-gitpython: GitPython: Arbitrary command execution via crafted kwargs (CVE-2026-76220) * python3.12-gitpython: GitPython: Arbitrary command execution via crafted kwargs (CVE-2026-76220) * python-gitpython: GitPython: Arbitrary File Overwrite via `git read-tree` option injection (CVE-2026-76219) * python3.12-gitpython: GitPython: Arbitrary File Overwrite via `git read-tree` option injection (CVE-2026-76219) * python-gitpython: GitPython: Arbitrary code execution via config-name injection (CVE-2026-76221) * python3.12-gitpython: GitPython: Arbitrary code execution via config-name injection (CVE-2026-76221)

Red Hat Ansible Automation Platform 2.5 has multiple security vulnerabilities affecting components such as automation-controller, automation-gateway, python3.12-aiohttp, python3.12-django, and python3.12-gitpython. These include remote code execution, server-side request forgery (SSRF), path traversal, denial of service, command injection, memory exhaustion, and environment variable exfiltration. The vulnerabilities have been addressed in a security update released by Red Hat.

**Target:** gitpython-developers/GitPython **Tested:** HEAD `07e80555` (2026-07-25), latest release 3.1.55, `git version 2.50.1` ## Summary `Repo.archive()` does call the option guard, so this is not a missing-guard report. The guard is present and working; the **denylist it consults is incomplete**. ```python # git/repo/base.py:169 unsafe_git_archive_options = [ # Allows arbitrary command execution through the remote git-upload-archive command. "--exec", # Writes output to a caller-controlled filesystem path. "--output", "-o", ] ``` The comment on `--output` states the protected class in the project's own words: an option that lets the caller name **a filesystem path** is unsafe. `--output` is blocked because it *writes* to a caller-chosen path. `git archive` also accepts `--add-file=<path>` and `--add-virtual-file=<path:content>` (both present in current git; verified against `git version 2.50.1`). `--add-file` *reads* a caller-chosen path — including an absolute path outside the repository — and places the bytes into the archive the caller receives. Neither option is in the list, and no other layer references them: ``` $ grep -rniE "add.file|add_file" git/ git/index/base.py:771: R"""Add files from the working tree, ... # unrelated docstring ``` Net effect: the guard blocks arbitrary file **write** at this sink while permitting arbitrary file **read** at the same sink. ## Reachability proof (verified at the sink) `poc/poc_addfile.py` at HEAD `07e80555`. The PoC creates its own out-of-tree canary, so it runs from a clean machine: ``` -- CONTROL: options the denylist covers (expect BLOCKED) -- [BLOCKED] output='/tmp/gp_written.tar': --output is not allowed, use `allow_unsafe_options=True` to allow it. [BLOCKED] o='/tmp/gp_written.tar': -o is not allowed, use `allow_unsafe_options=True` to allow it. [BLOCKED] exec='touch /tmp/gp_exec': --exec is not allowed, use `allow_unsafe_options=True` to allow it. -- SIBLING OMITTED FROM THE DENYLIST: --add-file (expect ALLOWED) -- [ALLOWED] add_file='/tmp/gp_canary.txt' -> archive 10240 bytes archive members: ['f.txt', 'gp_canary.txt'] >>> EXFILTRATED gp_canary.txt: 'secret-canary-12345' >>> byte-for-byte match with the out-of-tree file: CONFIRMED -- also: --add-virtual-file (attacker-chosen name AND content) -- [ALLOWED] add_virtual_file='pwn.txt:hello' -> archive 10240 bytes ``` The three blocked lines are the control: they prove the guard is active on this call path, so the fourth result is a gap in list membership rather than a guard that never ran. Minimal reproduction: ```python import io, tarfile from git import Repo buf = io.BytesIO() Repo("/path/to/repo").archive(buf, format="tar", add_file="/etc/passwd") print(tarfile.open(fileobj=io.BytesIO(buf.getvalue())).getnames()) # ['<repo files>', 'passwd'] <- contents readable by whoever receives the archive ``` The canary is untracked and lives outside the repository; its contents are recovered from the returned archive and asserted byte-for-byte against the on-disk file. The option is rendered by `transform_kwargs` into `--add-file=<path>` and reaches `git archive` unmodified. ## Direct precedent `GHSA-6p8h-3wgx-97gf` (High, published 2026-07-22) is the same defect on the sibling list: *"Incomplete `unsafe_git_clone_options` denylist omits `--template`"* — an option absent from one of these denylists, reachable under the same caller-controlled-options precondition, accepted and fixed by adding it. `git log` shows the archive list itself has already been extended reactively once, in `701ce32f` (*fix: Guard unsafe git command options*, GHSA-956x-8gvw-wg5v), and the `--template` omission was then fixed separately in `ffcb5359`. ## `--add-virtual-file` is the same gap pointing the other way `--add-virtual-file=<path:content>` lets the caller inject **attacker-chosen content under an attacker-chosen name** into an archive that downstream consumers will reasonably treat as repository-derived. ## Suggested remediation 1. **Preferred — allowlist.** `Repo.archive()` has a small legitimate option surface (`format`, `prefix`, `worktree_attributes`, `remote`, compression level, plus paths). Accepting those and rejecting the rest means a future git release cannot add another path-taking option that silently reopens this. 2. **Minimum — extend the list** with `--add-file` and `--add-virtual-file`, and make the membership rule *"the option takes a filesystem path or URL"* rather than *"the option executes a command"*. The existing comment on `--output` already implies that rule; applying it consistently is what closes the class instead of this instance. ## Scope limits - Impact is **arbitrary file read at the privileges of the process**. Not code execution — I make no such claim here. - It requires the embedding application to forward caller-influenced kwargs into `Repo.archive()`. That is the identical precondition to `--output`, `--exec` and `--template`,

**Target:** gitpython-developers/GitPython **Tested:** HEAD `07e80555` (2026-07-25), latest release 3.1.55, `git version 2.50.1` **Reported instances:** 2 exploitable, from a sweep of 14 unguarded call sites ## Summary GitPython blocks dangerous git options through `Git.check_unsafe_options()`, gated per method by an `allow_unsafe_options` parameter. That guard is applied **per call site**, so any API that forwards `**kwargs` into a git command without calling it passes caller-controlled options straight to git. A mechanical sweep of every method that forwards `**kwargs` into a `.git.<command>(...)` call found **14 sites with no guard**. Two reach a git option that takes a filesystem path: | # | Call site | git option | Impact | |---|---|---|---| | 1 | `IndexFile.checkout()` → `git checkout-index` | `--prefix=<path>` | arbitrary file **overwrite** with repository-controlled content | | 2 | `TagReference.create()` → `git tag` | `-F <file>` / `--file=<file>` | arbitrary file **read**, returned in-band | This is the same defect class already fixed in `Commit.count()` (GHSA-p538-c434-8v24), `Repo.archive()` and `Git.ls_remote()` (GHSA-956x-8gvw-wg5v). Both instances below are still present at HEAD. --- ## Instance 1 — `IndexFile.checkout()`: arbitrary file overwrite `git/index/base.py:1210` accepts `**kwargs` and forwards them with no guard: ```python def checkout(self, paths=None, force=False, fprogress=lambda *args: None, **kwargs): ... proc = self.repo.git.checkout_index(*args, **kwargs) # line 1331 ... proc = self.repo.git.checkout_index(args, **kwargs) # line 1349 ``` There is no `allow_unsafe_options` parameter and no `check_unsafe_options()` call in the method. `git checkout-index` accepts `--prefix=<string>`, prepended to every output path. It is not confined to the working tree, so an absolute prefix writes tracked file contents anywhere the process can write, and `-f` overwrites what is already there. ### Reproduction ```python from git import Repo Repo("/path/to/repo").index.checkout(prefix="/tmp/target_dir/", a=True, f=True) ``` Observed (`poc/poc_checkout_index.py`) — no exception raised, files land outside the repository: ``` [ALLOWED] no UnsafeOptionError raised files written outside the repo: ['f.txt'] f.txt: 'hi\n' ``` Overwrite of a pre-existing file (`poc/poc_ci_overwrite.py`) — the victim file held `ORIGINAL-DO-NOT-CLOBBER\n` before the call: ``` [ALLOWED] no exception victim content now: 'hi\n' OVERWRITTEN: True ``` ### Why this rates High Both halves of the write are attacker-influenced: - **Destination** — the `prefix` kwarg. - **Content** — the bytes written are repository blobs, so anyone who can land a file in the repository (a pull-request branch, a mirrored or untrusted repository, an agent-cloned repository) controls exactly what is written. Commit a file named `authorized_keys`, `.bashrc`, `config` or `post-checkout`, choose the matching prefix (`~/.ssh/`, `~/`, `.git/hooks/`), and the write becomes code execution as the service account. For comparison within this project: GHSA-fjr4-x663-mwxc (arbitrary file overwrite via `git diff --output`) is rated High, and GHSA-p538-c434-8v24 (arbitrary file *truncation* via `git rev-list --output`) is rated Medium. `--prefix` supplies full content control, so it sits at or above the former. --- ## Instance 2 — `TagReference.create()`: arbitrary file read `git/refs/tag.py:88` forwards `**kwargs` into `git tag` with no guard, and the signature advertises the passthrough: ```python def create(cls, repo, path, reference="HEAD", logmsg=None, force=False, **kwargs): """... :param kwargs: Additional keyword arguments to be passed to :manpage:`git-tag(1)`. """ ``` `git tag` accepts `-F <file>` / `--file=<file>`, which reads the tag message from an arbitrary path. The annotated tag object stores that content and GitPython returns it to the caller via `TagReference.tag.message`, so the file contents come back in-band. ### Reproduction ```python from git import Repo from git.refs.tag import TagReference t = TagReference.create(Repo("/path/to/repo"), "x", force=True, a=True, F="/etc/passwd") print(t.tag.message) ``` Observed (`poc/poc_tag_F.py`), reading a canary file outside the repository: ``` [ALLOWED] no UnsafeOptionError raised >>> tag message recovered from arbitrary path: 'TAG-READ-CANARY-98765\nsecond-line-secret' ``` Impact is a read at the privileges of the process. I am not claiming code execution for this instance. The signing options (`-s`, `-u`/`--local-user`) do invoke gpg from the same unguarded kwargs, but I did not develop that into command execution and make no claim about it. --- ## Sweep results — the other 12 sites Reported so the fix can be scoped once rather than per report. `poc/sweep.py` reproduces this list. | Call site | git command | Assessment | |---|---|---| | `IndexFile.from_tree()` | `read-tree` | `--index-output=<path>` looked reachable but i

CVE-2026-73620 affects GitPython methods used by the Snowflake CLI, allowing arbitrary file overwrite and arbitrary file read due to unguarded forwarding of git command options. Specifically, IndexFile.checkout() can overwrite files outside the repository using the --prefix option, and TagReference.create() can read arbitrary files via the -F/--file option. These vulnerabilities arise because certain API methods forward **kwargs to git commands without checking for unsafe options. The issue is present in versions >=3.4.1 and <3.24.0 of the snowflake-cli. A fix is available.