PyJWT versions up to 2.13.0 and current master before 2.26.0 contain a vulnerability where the HMAC verification accepts an empty key when using octet JWKs. This allows an attacker to forge tokens without knowing any secret if the application verifies tokens using a JWK/JWKS with an empty 'k' value. The issue arises because the empty key rejection implemented for string/bytes keys is not applied to keys loaded from JWKs. The vulnerability is fixed in PyJWT version 2.26.0.
The Model Context Protocol (MCP) Python SDK versions 1.10.0 through 1.29.1 and 2.0.0 through 2.1.1 contain a vulnerability where the client fetches server-declared external $ref URLs during tool output schema validation. This can cause the client to make network or local file requests synchronously without timeout, potentially stalling the client if the target is unresponsive. The issue is fixed in version 3.0.3.
The Model Context Protocol (MCP) Python SDK versions 1.8.0 through 1.29.1 and 2.0.0 through 2.1.1 have a vulnerability where HTTP client transports follow cross-origin redirects and send custom headers and, on 307/308 redirects, the request body to the redirected host. This can expose sensitive headers like X-API-Key if an attacker can cause a trusted endpoint to redirect to a malicious host. The Authorization bearer header is not exposed due to HTTP library protections. The issue is fixed in MCP SDK versions 3.0.3 and later.
A vulnerability in OpenTelemetry Python's opentelemetry-api package causes quadratic CPU cost when parsing the W3C tracestate header due to an unbounded optional-whitespace regular expression. This can lead to denial of service by blocking server workers for several seconds when processing large tracestate headers with many spaces or tabs. The issue affects versions from 1.0.0 through versions before 3.0.3. A fix is available in version 3.0.3.
Mistral vibe's GitPython integration has a vulnerability where the submodule creation function clones into the .git/hooks directory before validating the path. This allows an attacker to plant an executable hook script that runs on subsequent git operations, leading to arbitrary code execution. The issue affects versions from 2.1.0 up to but not including 3.0.3. Although versions 3.2.0 and later added stricter validation, the check occurs too late to prevent the malicious hook from being written. Versions 3.1.x do not perform this validation at all and silently allow the attack.
GitPython's Submodule.move() API does not properly handle symbolic links in intermediate path components, allowing an attacker-controlled symlink in a cloned repository to redirect submodule moves outside the parent repository worktree. This can cause the submodule checkout to be moved to an attacker-selected directory outside the worktree, corrupting the parent repository's index and configuration. The vulnerability requires the application to call Submodule.move() explicitly with a path under the symlink and affects GitPython versions before 3.0.3. No code execution or confidentiality impact is demonstrated.
GitPython versions up to 3.1.62 contain a vulnerability in the Head.checkout() method that allows an attacker to cause an arbitrary file read via a specially crafted branch name. The flaw arises because the branch name is passed as a positional argument to git checkout without proper sanitization or argument separation, enabling injection of git command options such as --pathspec-from-file. This can cause the contents of arbitrary files readable by the application process to be returned in exceptions. The issue is a regression or incomplete fix of prior advisories and affects all published releases up to 3.1.62. A fix is available in version 3.0.3.
GitPython's Remote.pull() method improperly handles the positional refspec argument, allowing an attacker to inject a --upload-pack option that bypasses the unsafe-option guard. This leads to arbitrary command execution with the privileges of the calling process when pulling from local-path or SSH transports. The vulnerability affects versions from 2.1.0 up to but not including 3.0.3 and is fixed in version 3.0.3.
GitPython versions >=2.1.0 and <3.0.3 contain vulnerabilities where three wrapper methods omit necessary unsafe protocol and option checks. The ls_remote method does not check for unsafe protocols, allowing remote code execution (RCE) if the victim's git transport policy permits the 'ext' protocol. The merge_base and IndexFile.move methods forward caller arguments without proper unsafe option checks, creating latent injection surfaces. These issues were verified on the main branch post the latest release. A fix is available in version 3.0.3.
Mistral vibe's GitPython parse_actor_and_date() function has a regex vulnerability causing quadratic backtracking on malformed author/committer/tagger lines missing or having malformed trailing epoch or timezone data. This leads to CPU exhaustion when processing crafted commit or tag objects. The issue affects versions from 2.1.0 up to but not including 3.0.3. A patch fixing the regex to prevent backtracking is available in version 3.0.3. The vulnerability can cause significant delays (seconds per access) in applications using GitPython to read untrusted repositories.
GitPython versions 2.1.0 up to but not including 3.0.3 contain a vulnerability where environment variables can be expanded from attacker-controlled .gitmodules submodule names during cloning operations. This leads to leakage of environment variable values both as persistent directory names on disk and in debug-level logs. The issue arises because the _clone() method does not disable environment variable expansion in Git.polish_url() for the separate_git_dir argument, unlike other similar calls. A fix is available in version 3.0.3.
CVE-2026-100689 is a path traversal vulnerability in GitPython 3.1.61 and main branch affecting the submodule update process. The vulnerability arises because the 'path' field from a .gitmodules file is used without proper containment validation, allowing an attacker to specify a directory outside the repository. This can lead to directory creation and population outside the intended repository path during submodule update operations targeting non-HEAD commits. The vulnerability is mitigated in version 2.26.0 by applying existing containment guards to the 'path' field.
GitPython versions prior to 3.2.0 contain a Regular Expression Denial of Service (ReDoS) vulnerability in the Actor.name_email_regex pattern used to parse commit author and committer metadata. The vulnerable regex causes catastrophic backtracking when processing a commit with an author or committer field containing a long string with an unterminated '<' character. This leads to quadratic CPU time growth proportional to input length, resulting in severe performance degradation and potential denial of service in any GitPython API call accessing commit author or committer information.
GitPython version 3.1.59 and versions >=2.1.0 <2.26.0 contain a vulnerability where the library incorrectly resolves the git directory path. This allows attacker-controlled repository content to impersonate the .git directory, causing GitPython to treat attacker-controlled files as internal git files, including executable hooks. This leads to arbitrary code execution when the victim performs a commit using GitPython's index.commit() method. Additionally, attackers can read sensitive files outside the repository and write config files to arbitrary locations. The issue arises because GitPython tests for git directory indicators in an order that considers the real .git directory last, allowing tracked files named gitdir, commondir, and HEAD to mislead the resolution. A fix is available in version 2.26.0.
GitPython versions prior to 2.26.0 contain a vulnerability in the TagReference.create() method where a positional 'reference' argument can bypass the intended unsafe option guard for '--file'. This allows an attacker to cause an arbitrary local file read, with the file contents returned as the annotated tag message. The issue arises because the unsafe option guard only inspects keyword arguments, not positional ones, enabling the bypass. A fix is available in version 2.26.0.
GitPython versions before 2.26.0 have an incomplete denylist for unsafe git revision options in the Repo.blame() and Repo.blame_incremental() methods. This flaw allows an attacker to use the --contents or -S options to read arbitrary local files by causing the file's lines to be included in the blame output. The vulnerability arises because these read-related options are not included in the denylist, which only blocks write-related options like --output. This leads to arbitrary file read at the privileges of the host process without requiring user interaction.
GitPython versions from 2.1.0 up to but not including 2.26.0 have a vulnerability where the clone_from() and clone() methods do not block the --separate-git-dir option by default, despite documentation stating they should. This allows an attacker controlling input to specify an arbitrary filesystem path for the Git metadata directory, leading to creation of repository metadata outside the intended clone destination. The flaw arises from an incomplete denylist of unsafe clone options, omitting --separate-git-dir, which is recognized as unsafe in other contexts within GitPython. The impact is arbitrary directory and file creation at attacker-controlled locations, bounded only by filesystem permissions of the running process. A fix is available in version 2.26.0.
CVE-2026-78676 is a critical vulnerability in GitPython's GitConfigParser affecting multi-line git-config values. The issue arises from improper re-serialization of multi-line config values read from disk, causing dormant values to be corrupted into live injected directives. This can lead to arbitrary code execution via the core.hooksPath configuration, which is honored by git hook operations. The vulnerability affects GitPython versions from 2.1.0 up to but not including 2.26.0 and is fixed in version 2.26.0.
GitPython versions from 2.1.0 up to but not including 2.26.0 contain a vulnerability where the SubmoduleConfigParser used to parse the .gitmodules file does not disable the merge_includes feature. This allows an attacker controlling the .gitmodules file to specify an [include] directive that references arbitrary local files. When the victim enumerates submodules, GitPython attempts to include and parse these files, and if the included file is not a valid git config, an exception is raised that leaks the first line of the file in the error message. This results in local file content disclosure of the first line of any readable file on the victim's system. The issue is fixed in version 2.26.0.
GitPython versions from 2.1.0 up to but not including 2.24.3 contain a vulnerability where an attacker-controlled submodule name in a cloned repository's .gitmodules file can cause GitPython to create and initialize a Git repository outside the intended working directory. This occurs because GitPython does not validate submodule names for directory traversal sequences before using them to construct filesystem paths. The vulnerability is fixed in version 2.24.3.