Integer overflow in Git before 2.7.4 allows remote attackers to execute arbitrary code via a (1) long filename or (2) many nested trees, which triggers a heap-based buffer overflow.

revision.c in git before 2.7.4 uses an incorrect integer data type, which allows remote attackers to execute arbitrary code via a (1) long filename or (2) many nested trees, leading to a heap-based buffer overflow.

A flaw was found in Git, a distributed revision control system. When parsing gitattributes, a mechanism to allow defining attributes for paths, multiple integer overflows can occur when there is a huge number of path patterns, attributes for a single pattern, or declared attribute names. These overflows can be triggered via a crafted .gitattributes file that may be part of the commit history. Git silently splits lines longer than 2KB when parsing gitattributes from a file, but not when parsing them from the index. Consequentially, the failure mode depends on whether the file exists in the working tree, the index, or both. This integer overflow can result in arbitrary heap reads and writes, which may allow remote code execution.

A flaw was found in Git, a distributed revision control system. This issue occurs due to an integer overflow in pretty.c::formatandpadcommit(), where a sizet is stored improperly as an int, and then added as an offset to a memcpy(). This overflow can be triggered directly by a user running a command which invokes the commit formatting machinery (e.g., git log --format=...). It may also be triggered indirectly through the git archive via the export-subst mechanism, which expands format specifiers inside files within the repository during a git archive. This integer overflow can result in arbitrary heap writes, which may allow arbitrary code execution.

A flaw was found in git which allows an attacker to execute arbitrary code by crafting a malicious .gitmodules file in a project cloned with --recurse-submodules.

References: https://bugzilla.novell.com/showbug.cgi?id=1110949 https://groups.google.com/forum/#!topic/git-packagers/fNLXf6LQC08

An issue was found in Git before v2.24.1, v2.23.1, v2.22.2, v2.21.1, v2.20.2, v2.19.3, v2.18.2, v2.17.3, v2.16.6, v2.15.4, and v2.14.6. When running Git in the Windows Subsystem for Linux (also known as "WSL") while accessing a working directory on a regular Windows drive, none of the NTFS protections were active.

Git before 1.8.5.6, 1.9.x before 1.9.5, 2.0.x before 2.0.5, 2.1.x before 2.1.4, and 2.2.x before 2.2.1 on Windows and OS X; Mercurial before 3.2.3 on Windows and OS X; Apple Xcode before 6.2 beta 3; mine all versions before 08-12-2014; libgit2 all versions up to 0.21.2; Egit all versions before 08-12-2014; and JGit all versions before 08-12-2014 allow remote Git servers to execute arbitrary commands via a tree containing a crafted .git/config file with (1) an ignorable Unicode codepoint, (2) a git~1/config representation, or (3) mixed case that is improperly handled on a case-insensitive filesystem.

Git before 2.19.2 on Linux and UNIX executes commands from the current working directory (as if '.' were at the end of $PATH) in certain cases involving the runcommand() API and run-command.c, because there was a dangerous change from execvp to execv during 2017.

Affected versions of Git have a vulnerability whereby Git can be tricked into sending private credentials to a host controlled by an attacker. Git uses external "credential helper" programs to store and retrieve passwords or other credentials from secure storage provided by the operating system. Specially-crafted URLs that contain an encoded newline can inject unintended values into the credential helper protocol stream, causing the credential helper to retrieve the password for one server (e.g., good.example.com) for an HTTP request being made to another server (e.g., evil.example.com), resulting in credentials for the former being sent to the latter. There are no restrictions on the relationship between the two, meaning that an attacker can craft a URL that will present stored credentials for any host to a host of their choosing. The vulnerability can be triggered by feeding a malicious URL to git clone. However, the affected URLs look rather suspicious; the likely vector would be through systems which automatically clone URLs not visible to the user, such as Git submodules, or package systems built around Git. The problem has been patched in the versions published on April 14th, 2020, going back to v2.17.x. Anyone wishing to backport the change further can do so by applying commit 9a6bbee (the full release includes extra checks for git fsck, but that commit is sufficient to protect clients against the vulnerability). The patched versions are: 2.17.4, 2.18.3, 2.19.4, 2.20.3, 2.21.2, 2.22.3, 2.23.2, 2.24.2, 2.25.3, 2.26.1.

Arbitrary command execution is possible in Git before 2.20.2, 2.21.x before 2.21.1, 2.22.x before 2.22.2, 2.23.x before 2.23.1, and 2.24.x before 2.24.1 because a "git submodule update" operation can run commands found in the .gitmodules file of a malicious repository.

Git before 2.10.5, 2.11.x before 2.11.4, 2.12.x before 2.12.5, 2.13.x before 2.13.6, and 2.14.x before 2.14.2 uses unsafe Perl scripts to support subcommands such as cvsserver, which allows attackers to execute arbitrary OS commands via shell metacharacters in a module name. The vulnerable code is reachable via git-shell even without CVS support.

Git is an open source, scalable, distributed revision control system. git shell is a restricted login shell that can be used to implement Git's push/pull functionality via SSH. In versions prior to 2.30.6, 2.31.5, 2.32.4, 2.33.5, 2.34.5, 2.35.5, 2.36.3, and 2.37.4, the function that splits the command arguments into an array improperly uses an int to represent the number of entries in the array, allowing a malicious actor to intentionally overflow the return value, leading to arbitrary heap writes. Because the resulting array is then passed to execv(), it is possible to leverage this attack to gain remote code execution on a victim machine. Note that a victim must first allow access to git shell as a login shell in order to be vulnerable to this attack. This problem is patched in versions 2.30.6, 2.31.5, 2.32.4, 2.33.5, 2.34.5, 2.35.5, 2.36.3, and 2.37.4 and users are advised to upgrade to the latest version. Disabling git shell access via remote logins is a viable short-term workaround.

An issue was found in Git before v2.24.1, v2.23.1, v2.22.2, v2.21.1, v2.20.2, v2.19.3, v2.18.2, v2.17.3, v2.16.6, v2.15.4, and v2.14.6. Recursive clones are currently affected by a vulnerability that is caused by too-lax validation of submodule names, allowing very targeted attacks via remote code execution in recursive clones.

contrib/completion/git-prompt.sh in Git before 1.9.3 does not sanitize branch names in the PS1 variable, allowing a malicious repository to cause code execution.

A flaw was found in the way the Git client handles "ssh://" URLs. A maliciously crafted "ssh://" URL would cause Git clients to run an arbitrary shell command. Such a URL could be generated by a malicious server, by a malicious users committing to an honest server (to attack another user of that server's repositories), or by a proxy server.

GIT version 2.15.1 and earlier contains a Input Validation Error vulnerability in Client that can result in problems including messing up terminal configuration to RCE. This attack appear to be exploitable via The user must interact with a malicious git server, (or have their traffic modified in a MITM attack).

Git GUI is a convenient graphical tool that comes with Git for Windows. Its target audience is users who are uncomfortable with using Git on the command-line. Git GUI has a function to clone repositories. Immediately after the local clone is available, Git GUI will automatically post-process it, among other things running a spell checker called aspell.exe if it was found. Git GUI is implemented as a Tcl/Tk script. Due to the unfortunate design of Tcl on Windows, the search path when looking for an executable always includes the current directory. Therefore, malicious repositories can ship with an aspell.exe in their top-level directory which is executed by Git GUI without giving the user a chance to inspect it first, i.e. running untrusted code. This issue has been addressed in version 2.39.1. Users are advised to upgrade. Users unable to upgrade should avoid using Git GUI for cloning. If that is not a viable option, at least avoid cloning from untrusted sources.

An attacker can prepare a local repository in such a way that, when cloned, will execute arbitrary code during the operation.

CVE-2025-48384 is regarding a vulnerability in Git where when reading a config value, Git strips any trailing carriage return and line feed (CRLF). When writing a config entry, values with a trailing CR are not quoted, causing the CR to be lost when the config is later read. When initializing a submodule, if the submodule path contains a trailing CR, the altered path is read resulting in the submodule being checked out to an incorrect location. If a symlink exists that points the altered path to the submodule hooks directory, and the submodule contains an executable post-checkout hook, the script may be unintentionally executed after checkout. GitHub created this CVE on their behalf. The documented Visual Studio updates incorporate updates in Git which address this vulnerability. Please see CVE-2025-48384 for more information.

Git is an open-source distributed revision control system. In affected versions of Git a specially crafted repository that contains symbolic links as well as files using a clean/smudge filter such as Git LFS, may cause just-checked out script to be executed while cloning onto a case-insensitive file system such as NTFS, HFS+ or APFS (i.e. the default file systems on Windows and macOS). Note that clean/smudge filters have to be configured for that. Git for Windows configures Git LFS by default, and is therefore vulnerable. The problem has been patched in the versions published on Tuesday, March 9th, 2021. As a workaound, if symbolic link support is disabled in Git (e.g. via git config --global core.symlinks false), the described attack won't work. Likewise, if no clean/smudge filters such as Git LFS are configured globally (i.e. before cloning), the attack is foiled. As always, it is best to avoid cloning repositories from untrusted sources. The earliest impacted version is 2.14.2. The fix versions are: 2.30.1, 2.29.3, 2.28.1, 2.27.1, 2.26.3, 2.25.5, 2.24.4, 2.23.4, 2.22.5, 2.21.4, 2.20.5, 2.19.6, 2.18.5, 2.17.62.17.6.

Git is a revision control system. The Git project recommends to avoid working in untrusted repositories, and instead to clone it first with git clone --no-local to obtain a clean copy. Git has specific protections to make that a safe operation even with an untrusted source repository, but vulnerabilities allow those protections to be bypassed. In the context of cloning local repositories owned by other users, this vulnerability has been covered in CVE-2024-32004. But there are circumstances where the fixes for CVE-2024-32004 are not enough: For example, when obtaining a .zip file containing a full copy of a Git repository, it should not be trusted by default to be safe, as e.g. hooks could be configured to run within the context of that repository. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4. As a workaround, avoid using Git in repositories that have been obtained via archives from untrusted sources.

A vulnerability was found in Git. This flaw occurs due to Git not checking the ownership of directories in a local multi-user system when running commands specified in the local repository configuration. This issue allows the owner of the repository to cause arbitrary commands to be executed by other users who access the repository.

A vulnerability was found in Git. This security flaw occurs when renaming or deleting a section from a configuration file, where certain malicious configuration values may be misinterpreted as the beginning of a new configuration section. This flaw leads to arbitrary configuration injection.

A flaw was found in git which allows arbitrary code to be executed when running 'git clone --recurse-submodules (or the deprecated 'git clone --recursive' synonym). A malicious repository can include a .gitmodules submodule config file which points outside of the repository. When git clones such a repository it can be tricked into running hooks within the cloned submodule, which is under the control of the attacker.

References: https://public-inbox.org/git/xmqqy3g2flb6.fsf@gitster-ct.c.googlers.com/ https://www.edwardthomson.com/blog/upgradinggitforcve201811235.html https://news.ycombinator.com/item?id=17181238

A vulnerability was found in Git. This flaw occurs due to Git not checking the ownership of directories in a local multi-user system when running commands specified in the local repository configuration. This allows the owner of the repository to cause arbitrary commands to be executed by other users who access the repository.

Affected versions of Git have a vulnerability whereby Git can be tricked into sending private credentials to a host controlled by an attacker. This bug is similar to CVE-2020-5260(GHSA-qm7j-c969-7j4q). The fix for that bug still left the door open for an exploit where some credential is leaked (but the attacker cannot control which one). Git uses external "credential helper" programs to store and retrieve passwords or other credentials from secure storage provided by the operating system. Specially-crafted URLs that are considered illegal as of the recently published Git versions can cause Git to send a "blank" pattern to helpers, missing hostname and protocol fields. Many helpers will interpret this as matching any URL, and will return some unspecified stored password, leaking the password to an attacker's server. The vulnerability can be triggered by feeding a malicious URL to git clone. However, the affected URLs look rather suspicious; the likely vector would be through systems which automatically clone URLs not visible to the user, such as Git submodules, or package systems built around Git. The root of the problem is in Git itself, which should not be feeding blank input to helpers. However, the ability to exploit the vulnerability in practice depends on which helpers are in use. Credential helpers which are known to trigger the vulnerability: - Git's "store" helper - Git's "cache" helper - the "osxkeychain" helper that ships in Git's "contrib" directory Credential helpers which are known to be safe even with vulnerable versions of Git: - Git Credential Manager for Windows Any helper not in this list should be assumed to trigger the vulnerability.

A vulnerability was found in Git. This security flaw occurs when feeding specially crafted input to git apply --reject; a path outside the working tree can be overwritten with partially controlled contents corresponding to the rejected hunk(s) from the given patch.

A user can feed a specially crafted input to git apply to overwrite a path outside the working tree.

A buffer overrun was found in the way Git sanitized path of a git directory. If a local attacker would create a specially-crafted working copy and trick the local user into running any git command, it could lead to arbitrary code execution with the privileges of the user running the Git command.

References: [1] http://seclists.org/oss-sec/2010/q3/93 [2] https://bugzilla.redhat.com/showbug.cgi?id=617422

Upstream patches: [3] http://git.kernel.org/?p=git/git.git;a=commitdiff;h=3c9d0414ed2db0167e6c828b547be8fc9f88fccc;hp=c173dad58787a7f11a526dbcdaa5a2fe9ff1c87f [4] http://git.kernel.org/?p=git/git.git;a=commitdiff;h=b44ebb19e3234c5dffe9869ceac5408bb44c2e20;hp=2a5fe2545882721d6841bad11dae0f15b454bf0d

Git before versions 2.13.7, 2.14.4, 2.15.2, 2.16.4 and 2.17.1 performs path sanity-checks in isntfsdotgit():path.c that can be fooled into reading arbitrary memory.

Upstream announcement: https://marc.info/?l=git&m=152761328506724&w=2