Vulnerabilities

CVE-2026-85706 is a path traversal flaw (CWE-35) in GitLab Community Edition and Enterprise Edition in which the repository commits API does not properly confine file paths and does not enforce authentication, allowing an unauthenticated attacker to read arbitrary files from the GitLab server. It is triggered by sending a crafted unauthenticated request to the commits API that supplies traversal sequences moving outside the intended repository path. An attacker gains the ability to read arbitrary files on the host, which can expose configuration files, certificates, and stored credentials or keys; related reporting on the recent GitLab patch wave also notes credential theft and code execution flaws, though this CVE itself is the file-read issue. All self-managed GitLab CE and EE deployments are in scope, and CISA did not publish specific affected version ranges in this data. The flaw was added to CISA's KEV catalog on 2026-09-11 and is being actively probed and exploited in the wild within a day of disclosure, with three public proof-of-concept repositories available; ransomware use is not yet confirmed.

Do: Upgrade GitLab CE/EE to the patched release identified in GitLab's security advisory (no specific fixed version number is provided in this data), prioritizing internet-facing instances in line with CISA BOD 26-04; if patching is not immediately possible, restrict exposure and review access logs for unauthenticated requests to the commits API containing path traversal sequences. Because arbitrary file read can expose server-side secrets, inventory and rotate credentials, tokens, and keys stored on or reachable by affected GitLab hosts.

GitPython before 3.1.60 fails to properly validate the location of the git directory, which lets an attacker impersonate it using tracked files such as gitdir, commondir, and HEAD. An attacker who can get a victim to clone or open a crafted repository can plant a malicious pre-commit hook in the tracked hooks directory. When the victim's code then calls index.commit() on that repository, the hook executes, giving the attacker arbitrary code execution with the privileges of the process running GitPython. Anyone running affected versions in workflows that process untrusted or attacker-influenced repositories — such as CI/CD pipelines, automation, and developer tooling — is affected, while purely local, fully trusted repository use is largely out of scope. No public proof-of-concept is known, the issue is not in CISA KEV, and no in-the-wild exploitation has been reported.

Do: Upgrade GitPython to 3.1.60 or later. As interim mitigation, avoid calling index.commit() or other hook-triggering operations on repositories cloned from untrusted sources, and audit dependency trees and CI images for GitPython versions below 3.1.60. When reviewing untrusted repositories, look for tracked files named gitdir, commondir, or HEAD and unexpected files in a tracked hooks directory.

Gitea before 1.27.1 contains a critical code injection flaw (CWE-94) in the diffpatch API that allows remote code execution by causing the installation of a Git hook. An attacker can submit a crafted request through the diffpatch API to plant a Git hook, which then executes arbitrary shell commands on the server when Git operations run; the CVSS vector indicates the attack requires no authentication or user interaction, while public reporting describes attackers with repository write access planting hooks to run shell commands. Successful exploitation yields full server compromise (confidentiality, integrity, and availability all rated high), and observed attacks have reportedly dropped a cryptocurrency miner. All Gitea deployments running versions prior to 1.27.1 are affected, with internet-facing instances at greatest risk; public scans identified over 8,300 vulnerable Gitea servers. The flaw is actively exploited in the wild: CISA added it to the Known Exploited Vulnerabilities catalog on 2026-08-25, and EPSS estimates an 86.8% probability of exploitation within 30 days.

Do: Upgrade Gitea to version 1.27.1 or later immediately; organizations subject to BOD 26-04 must apply the vendor mitigation or discontinue use of unpatched cloud-hosted instances. Until patched, limit internet exposure of Gitea servers and inspect repository hook directories for unauthorized or recently modified hooks that could serve as persistence. Check for signs of compromise, including unexpected processes or cryptocurrency-miner activity, since in-the-wold attacks reportedly deploy a miner.

GitPython's GitConfigParser contains a configuration-injection flaw (CWE-88/CWE-94) in its read-then-write round trip: multi-line values parsed from an on-disk config file using git's standard backslash-continuation syntax are decoded into Python strings with embedded newlines, and when the parser later rewrites the file, write_section() serializes them as a bare, unquoted newline-plus-tab continuation that real git parses as separate top-level config lines. The recently added UNSAFE_CONFIG_CHARS_RE safety guard only applies to values passed directly to set()/set_value()/add_value()/add_section(), never to values loaded from disk via _read(), so any unrelated write can turn a dormant value into a live directive such as core.hooksPath = <attacker-controlled path>. An attacker who can plant such a value in a config file that a GitPython-based application later rewrites gains arbitrary code execution, because git will execute the attacker's hook programs with the privileges of the user running GitPython. Developers, CI/CD systems, and pip-packaged tools that embed GitPython and rewrite git config files are affected, with GitPython 3.1.58 at HEAD confirmed vulnerable. No public PoC exists, it is not in CISA KEV, and EPSS assigns only a 0.4% probability of exploitation within 30 days, so no exploitation is currently known.

Do: Monitor GitPython for a patched release beyond 3.1.58/commit 9729ed3b (no fixed version is identified in the available data) and upgrade as soon as one is published. In the interim, avoid letting GitConfigParser rewrite config files that may contain multi-line (backslash-continuation) values, audit managed .git/config and related files for values with embedded newlines or unexpected trailing fragments like hooksPath, and restrict write access to those files to trusted principals.

GitPython before 3.1.58 contains a flaw (CWE-88) in its check_unsafe_options guard, which is meant to block unsafe git options while allow_unsafe_options is set to its default value of False. The guard can be bypassed by combining a single-character keyword argument with split_single_char_options=False, causing GitPython to emit a joined token that git itself parses as an --upload-pack option. An attacker who can influence the kwargs passed to guarded methods such as clone_from can therefore inject --upload-pack and achieve arbitrary OS command execution, despite the library's default safe configuration. Any Python application, service, or pipeline built on the pip-installed GitPython library that passes attacker-controlled or remotely influenced arguments into its git wrapper methods is affected. A public proof-of-concept reference exists via the project's GitHub security advisory (GHSA-wvpp-8hx9-p66j); there is no evidence of in-the-wild exploitation yet, and EPSS puts 30-day exploitation probability at roughly 0.6%.

Do: Upgrade to GitPython 3.1.58 or later via pip as soon as possible. Audit application code paths where user or remote input flows into kwargs of guarded GitPython methods (e.g., clone_from), and avoid combining split_single_char_options=False with single-character keyword arguments until patched. No in-the-wild exploitation is confirmed, but given the public advisory, prioritize updates for internet-facing services that wrap git operations.

GitPython versions before 3.1.54 contain an OS command injection flaw (CWE-78) in which the check_unsafe_options guard intended to block dangerous git options can be bypassed by smuggling git options inside single-character kwarg values. An attacker who can influence the option dictionaries passed to commonly used methods — clone_from, fetch, pull, push, ls_remote, iter_commits, blame, or archive — can inject the --upload-pack parameter to execute arbitrary OS commands on the host. Successful exploitation yields remote code execution with the privileges of the Python process running GitPython (CVSS 4.0: 8.7, high). Any Python application, service, or CI/automation tooling built on affected GitPython versions where attacker-controlled data reaches these git option arguments is affected. No confirmed in-the-wild exploitation yet (not in CISA KEV, EPSS ~0.7%), but a public advisory and proof-of-concept reference exist, so weaponization is straightforward.

Do: Upgrade to GitPython 3.1.54 or later. Interim mitigation: audit all code paths that pass user- or attacker-controlled arguments or option dictionaries into clone_from, fetch, pull, push, ls_remote, iter_commits, blame, or archive, and validate that option values (especially short/single-character kwargs) cannot smuggle extra git options such as --upload-pack. Review web applications and automation that invoke git via GitPython to confirm whether untrusted input reaches these parameters.

GitPython 3.1.50 contains a command-injection flaw (CWE-78) in which the library's default unsafe-option gate fails to recognize joined short-option forms such as -u, the short form of --upload-pack=. The flaw is triggered when an application passes attacker-influenced options into Repo.clone_from(..., multi_options=..., allow_unsafe_options=False): the attacker supplies -u with a value of their choosing, bypassing the gate that is supposed to block --upload-pack/-u. During the clone, Git then executes the helper command named by the -u option, giving the attacker arbitrary command execution on the host running GitPython, in the context of the cloning process. Any application built on GitPython 3.1.50 that forwards untrusted, user-controlled clone options is affected; deployments that do not pass attacker-influenced options are not exposed. There is one public proof-of-concept reference (the project's GitHub security advisory GHSA-v396-v7q4-x2qj); the flaw is not in CISA KEV, EPSS is 0.4%, and no in-the-wild exploitation is currently reported.

Do: Upgrade to GitPython 3.1.51 or later, which recognizes joined short-option forms in the unsafe-option gate. Until patched, do not pass attacker-controlled arguments to Repo.clone_from via multi_options, and audit applications that let users supply clone options (including short options like -u) for this pattern.

GitHub MCP Server versions prior to 1.1.0 contain a nil pointer dereference (CWE-476) in the CompletionsHandler function in pkg/github/server.go, which accesses the ref field of a completion request without first verifying it is present. Any unauthenticated client able to send JSON-RPC messages to the server can trigger the flaw by issuing a completion/complete request with a missing or empty ref field. Because the dereference happens before any authentication or token validation, the resulting Go runtime panic crashes the server and yields a complete denial of service. All deployments running an affected version are potentially affected, with the greatest risk for instances reachable over a network by unauthenticated clients, while locally run stdio instances are only reachable by their local client. No widespread exploitation is reported (0.4% EPSS, not in CISA KEV), but a public security advisory documents the issue and the triggering request is trivial to craft.

Do: Upgrade to GitHub MCP Server 1.1.0 or later, which adds the missing nil check in CompletionsHandler. Until patched, restrict any HTTP/SSE-exposed instance with authentication or network allowlisting, since the crashing request requires no credentials. Audit deployments to determine which are network-reachable versus local-only, and watch for unauthenticated completion/complete requests that crash the process.