Impact

When populating a Git repository's working tree with the contents of Git LFS objects, certain Git LFS commands may write to files visible outside the current Git working tree if symbolic or hard links exist which collide with the paths of files tracked by Git LFS.

Git LFS has resolved this problem by revising the git lfs checkout and git lfs pull commands so that they check for symbolic links in the same manner as performed by Git before writing to files in the working tree. These commands now also remove existing files in the working tree before writing new files in their place.

As well, Git LFS has resolved a problem whereby the git lfs checkout and git lfs pull commands, when run in a bare repository, could write to files visible outside the repository. While a specific and relatively unlikely set of conditions were required for this to occur, it is no longer possible under any circumstances.

Patches

This problem exists in all versions since 0.5.2 and is patched in v3.7.1. All users should upgrade to v3.7.1.

Workarounds

Support for symlinks in Git may be disabled by setting the core.symlinks configuration option to false, after which further clones and fetches will not create symbolic links. However, any symbolic or hard links in existing repositories will still provide the opportunity for Git LFS to write to their targets.

References

- https://github.com/git-lfs/git-lfs/security/advisories/GHSA-6pvw-g552-53c5 - https://nvd.nist.gov/vuln/detail/CVE-2025-26625 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-26625 - https://github.com/git-lfs/git-lfs/releases/tag/v3.7.1 - git-lfs/git-lfs@5c11ffce9a - git-lfs/git-lfs@0cffe93176 - git-lfs/git-lfs@d02bd13f02

For more information

If there are any questions or comments about this advisory: For general questions, start a discussion in the Git LFS discussion forum. For reports of additional vulnerabilities, please follow the Git LFS security reporting policy.

The flaw, tracked as CVE-2025-48384 (CVSS score of 8.1), is described as an arbitrary file write during the cloning of repositories with submodules that use a ‘recursive’ flag.

The issue exists because, when reading configuration values, Git strips trailing carriage return (CR) characters and does not quote them when writing.

Thus, the initialization of submodules with a path containing a trailing CR results in altered paths and 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,” Git’s advisory reads.

https://lore.kernel.org/git/xmqq5xg2wrd1.fsf@gitster.g

https://www.helpnetsecurity.com/2025/08/26/git-vulnerability-exploited-cve-2025-48384/

Git GUI allows you to use the Git source control management tools via a GUI. When a user clones an untrusted repository and is tricked into editing a file located in a maliciously named directory in the repository, then Git GUI can create and overwrite files for which the user has write permission. This vulnerability is fixed in 2.43.7, 2.44.4, 2.45.4, 2.46.4, 2.47.3, 2.48.2, 2.49.1, and 2.50.1.

A Git repository can be crafted in such a way that a user who has cloned the repository can be tricked into running any script supplied by the attacker by invoking gitk filename, where filename has a particular structure.

When a user clones an untrusted repository and runs Gitk without additional command arguments, any writable file can be created and truncated. The option "Support per-file encoding" must have been enabled. The operation "Show origin of this line" is affected as well, regardless of the option being enabled or not.

Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals. 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. This vulnerability is fixed in v2.43.7, v2.44.4, v2.45.4, v2.46.4, v2.47.3, v2.48.2, v2.49.1, and v2.50.1.

Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals. When cloning a repository Git knows to optionally fetch a bundle advertised by the remote server, which allows the server-side to offload parts of the clone to a CDN. The Git client does not perform sufficient validation of the advertised bundles, which allows the remote side to perform protocol injection. This protocol injection can cause the client to write the fetched bundle to a location controlled by the adversary. The fetched content is fully controlled by the server, which can in the worst case lead to arbitrary code execution. The use of bundle URIs is not enabled by default and can be controlled by the bundle.heuristic config option. Some cases of the vulnerability require that the adversary is in control of where a repository will be cloned to. This either requires social engineering or a recursive clone with submodules. These cases can thus be avoided by disabling recursive clones. This vulnerability is fixed in v2.43.7, v2.44.4, v2.45.4, v2.46.4, v2.47.3, v2.48.2, v2.49.1, and v2.50.1.

The Git project released new versions of Git today, July 8, 2025, addressing multiple security vulnerabilities. Those vulnerabilities are: CVE-2025-27613, CVE-2025-27614, CVE-2025-46334, CVE-2025-46835, CVE-2025-48384, CVE-2025-48385, and CVE-2025-48386.

The new versions are v2.43.7, v2.44.4, v2.45.4, v2.46.4, v2.47.3, v2.48.2, and v2.49.1. Many previous versions older than <= v2.50.0 are affected.

The announcement from the Git project's mailing list may be found at:

https://lore.kernel.org/git/xmqq5xg2wrd1.fsf@gitster.g/

We recommend upgrading. The addressed issues are as follows:

CVE-2025-27613, Gitk:

When a user clones an untrusted repository and runs Gitk without additional command arguments, any writable file can be created and truncated. The option "Support per-file encoding" must have been enabled. The operation "Show origin of this line" is affected as well, regardless of the option being enabled or not.

CVE-2025-27614, Gitk:

A Git repository can be crafted in such a way that a user who has cloned the repository can be tricked into running any script supplied by the attacker by invoking gitk filename, where filename has a particular structure.

CVE-2025-46334, Git GUI (Windows only):

A malicious repository can ship versions of sh.exe or typical textconv filter programs such as astextplain. On Windows, path lookup can find such executables in the worktree. These programs are invoked when the user selects "Git Bash" or "Browse Files" from the menu.

CVE-2025-46835, Git GUI:

When a user clones an untrusted repository and is tricked into editing a file located in a maliciously named directory in the repository, then Git GUI can create and overwrite any writable file.

CVE-2025-48384, Git:

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.

CVE-2025-48385, Git:

When cloning a repository Git knows to optionally fetch a bundle advertised by the remote server, which allows the server-side to offload parts of the clone to a CDN. The Git client does not perform sufficient validation of the advertised bundles, which allows the remote side to perform protocol injection.

This protocol injection can cause the client to write the fetched bundle to a location controlled by the adversary. The fetched content is fully controlled by the server, which can in the worst case lead to arbitrary code execution.

CVE-2025-48386, Git:

The wincred credential helper uses a static buffer (target) as a unique key for storing and comparing against internal storage. This credential helper does not properly bounds check the available space remaining in the buffer before appending to it with wcsncat(), leading to potential buffer overflows.

Credit for discovering CVEs 2025-48384, 48385, and 48386 goes to David Leadbeater. Credit for fixing the first two CVEs goes to Justin Tobler, and Patrick Steinhardt, respectively. Credit for fixing the third CVE is shared between Taylor Blau, and Jeff King.

Credit for finding and fixing CVE-2025-46835 goes to Johannes Sixt. Mark Levedahl discovered and fixed CVE-2025-46334. Avi Halachmi discovered both CVE-2025-27613 and CVE-2025-27614, and fixed the latter. CVE-2025-27613 was fixed by Johannes Sixt.

Thanks, Taylor

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.

Hi,

On Tue, Jan 14, 2025 at 07:02:40PM +0100, Johannes Schindelin wrote: Team,

The Git project released new security bug-fix versions today, January 14th, 2025: v2.48.1, v2.47.1, v2.46.3, v2.45.3, v2.44.3, v2.43.6, v2.42.4, v2.41.3, and v2.40.4. Small heads-up here: I think in the above version listing it should be v2.47.2 instead. The other versions are correct.

Regards, Salvatore

Git is a source code management tool. When cloning from a server (or fetching, or pushing), informational or error messages are transported from the remote Git process to the client via the so-called "sideband channel". These messages will be prefixed with "remote:" and printed directly to the standard error output. Typically, this standard error output is connected to a terminal that understands ANSI escape sequences, which Git did not protect against. Most modern terminals support control sequences that can be used by a malicious actor to hide and misrepresent information, or to mislead the user into executing untrusted scripts. As requested on the git-security mailing list, the patches are under discussion on the public mailing list. Users are advised to update as soon as possible. Users unable to upgrade should avoid recursive clones unless they are from trusted sources.

Git is a source code management tool. When cloning from a server (or fetching, or pushing), informational or error messages are transported from the remote Git process to the client via the so-called "sideband channel". These messages will be prefixed with "remote:" and printed directly to the standard error output. Typically, this standard error output is connected to a terminal that understands ANSI escape sequences, which Git did not protect against. Most modern terminals support control sequences that can be used by a malicious actor to hide and misrepresent information, or to mislead the user into executing untrusted scripts. As requested on the git-security mailing list, the patches are under discussion on the public mailing list. Users are advised to update as soon as possible. Users unable to upgrade should avoid recursive clones unless they are from trusted sources.

Git LFS is a Git extension for versioning large files. When Git LFS requests credentials from Git for a remote host, it passes portions of the host's URL to the git-credential(1) command without checking for embedded line-ending control characters, and then sends any credentials it receives back from the Git credential helper to the remote host. By inserting URL-encoded control characters such as line feed (LF) or carriage return (CR) characters into the URL, an attacker may be able to retrieve a user's Git credentials. This problem exists in all previous versions and is patched in v3.6.1. All users should upgrade to v3.6.1. There are no workarounds known at this time.

Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals. Git defines a line-based protocol that is used to exchange information between Git and Git credential helpers. Some ecosystems (most notably, .NET and node.js) interpret single Carriage Return characters as newlines, which renders the protections against CVE-2020-5260 incomplete for credential helpers that treat Carriage Returns in this way. This issue has been addressed in commit b01b9b8 which is included in release versions v2.48.1, v2.47.1, v2.46.3, v2.45.3, v2.44.3, v2.43.6, v2.42.4, v2.41.3, and v2.40.4. Users are advised to upgrade. Users unable to upgrade should avoid cloning from untrusted URLs, especially recursive clones.

Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals. When Git asks for credentials via a terminal prompt (i.e. without using any credential helper), it prints out the host name for which the user is expected to provide a username and/or a password. At this stage, any URL-encoded parts have been decoded already, and are printed verbatim. This allows attackers to craft URLs that contain ANSI escape sequences that the terminal interpret to confuse users e.g. into providing passwords for trusted Git hosting sites when in fact they are then sent to untrusted sites that are under the attacker's control. This issue has been patch via commits 7725b81 and c903985 which are included in release versions v2.48.1, v2.47.1, v2.46.3, v2.45.3, v2.44.3, v2.43.6, v2.42.4, v2.41.3, and v2.40.4. Users are advised to upgrade. Users unable to upgrade should avoid cloning from untrusted URLs, especially recursive clones.

Git does not sanitize URLs when asking for credentials interactively

Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals. Git defines a line-based protocol that is used to exchange information between Git and Git credential helpers. Some ecosystems (most notably, .NET and node.js) interpret single Carriage Return characters as newlines, which renders the protections against CVE-2020-5260 incomplete for credential helpers that treat Carriage Returns in this way. This issue has been addressed in commit b01b9b8 which is included in release versions v2.48.1, v2.47.1, v2.46.3, v2.45.3, v2.44.3, v2.43.6, v2.42.4, v2.41.3, and v2.40.4. Users are advised to upgrade. Users unable to upgrade should avoid cloning from untrusted URLs, especially recursive clones.

Team,

The Git project released new security bug-fix versions today, January 14th, 2025: v2.48.1, v2.47.1, v2.46.3, v2.45.3, v2.44.3, v2.43.6, v2.42.4, v2.41.3, and v2.40.4.

The addressed issues are:

- CVE-2024-50349:

Printing unsanitized URLs when asking for credentials makes the user susceptible to crafted URLs (e.g. in recursive clones). These URLs can mislead the user into typing in passwords for trusted sites that would then be sent to untrusted sites instead.

A potential scenario of how this can be exploited is a recursive clone where one of the submodules prompts for a password, pretending to ask for a different host than the password will be sent to.

- CVE-2024-52006:

Git may pass on Carriage Returns via the credential protocol to credential helpers which use line-reading functions that interpret Carriage Returns as line endings, even though this is not what was intended (but Git’s documentation did not clarify that "newline" meant "Line Feed character").

This affected the popular .NET-based Git Credential Manager, which has been updated accordingly in coordination with the Git project.

Ciao, Johannes

An argument injection on Git during retrieval of repository history leads to remote code execution on the Pagure instance.

Team,

The Git project released new security bug-fix versions today, May 14th, 2024: v2.45.1, v2.44.1, v2.43.4, v2.42.2, v2.41.1, v2.40.2, and v2.39.4.

The addressed issues are:

CVE-2024-32002 (https://github.com/git/git/security/advisories/GHSA-8h77-4q3w-gfgv):

Recursive clones on case-insensitive filesystems that support symbolic links are susceptible to case confusion that can be exploited to execute just-cloned code during the clone operation.

This allows the attack where a recursive clone would first initialize a submodule, then replace its parent directory with a symbolic link into the .git/ directory where the second stage of the recursive clone would then write e.g. hooks that would be immediately executed before the user has had a chance to inspect what is getting executed.

Credit for finding the vulnerability goes to Filip Hejsek, credit for fixing it goes to Johannes Schindelin.

CVE-2024-32004 (https://github.com/git/git/security/advisories/GHSA-xfc6-vwr8-r389):

Repositories can be configured to execute arbitrary code during local clones. To address this, the ownership checks introduced in v2.30.3 are now extended to cover cloning local repositories.

The most obvious attack vector is to prepare a local partial clone that is intentionally missing objects, override in its config what upload-pack executable use, and then talk another user on the same machine to clone that. This will run that configured upload-pack executable under using person's permissions.

Credit for finding the vulnerability goes to Filip Hejsek, credit for fixing it goes to Johannes Schindelin.

CVE-2024-32020 (https://github.com/git/git/security/advisories/GHSA-5rfh-556j-fhgj):

Local clones may end up hardlinking files into the target repository's object database when source and target repository reside on the same disk. If the source repository is owned by a different user, then those hardlinked files may be rewritten at any point in time by the untrusted user.

This vulnerability allows a bait-and-switch attack where individual objects are replaced in already-indexed pack file; Git will not verify that the object's contents match its recorded object ID in that case.

Credit for finding and for fixing the vulnerability goes to Patrick Steinhardt.

CVE-2024-32021 (https://github.com/git/git/security/advisories/GHSA-mvxm-9j2h-qjx7):

When cloning a local source repository that contains symlinks via the filesystem, Git may create hardlinks to arbitrary user-readable files on the same filesystem as the target repository in the objects/ directory.

This allows the same attack vector that CVE-2022-39253 tried to prevent, by exploiting a time-of-check-time-of-use race.

Credit for finding and for fixing the vulnerability goes to Patrick Steinhardt.

CVE-2024-32465 (https://github.com/git/git/security/advisories/GHSA-vm9j-46j9-qvq4):

It is supposed to be safe to clone untrusted repositories, even those unpacked from zip archives or tarballs originating from untrusted sources, but Git can be tricked to run arbitrary code as part of the clone.

The attack vectors are the same as for the CVEs mentioned above that involve local clones, but social-engineering is required to manipulate a user into unpacking a .zip file and running Git commands on the unpacked files.

Credit for finding and for fixing the vulnerability goes to Jeff King.

Note: the defense-in-depth protection in these new Git versions causes a regression when cloning repositories enabled with Git LFS. The clone will fail with an error message. The remedy is to call git lfs pull in the fresh clone.

Thanks, Johannes

Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, repositories with submodules can be crafted in a way that exploits a bug in Git whereby it can be fooled into writing files not into the submodule's worktree but into a .git/ directory. This allows writing a hook that will be executed while the clone operation is still running, giving the user no opportunity to inspect the code that is being executed. 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. If symbolic link support is disabled in Git (e.g. via git config --global core.symlinks false), the described attack won't work. As always, it is best to avoid cloning repositories from untrusted sources.

Git Credential Manager (GCM) is a secure Git credential helper. Prior to 2.5.0, the Debian package does not set root ownership on installed files. This allows user 1001 on a multi-user system can replace binary and gain other users' privileges. This vulnerability is fixed in 2.5.0.

CVE-2023-25815: When Git is compiled with runtime prefix support and runs without translated messages, it still used the gettext machinery to display messages, which subsequently potentially looked for translated messages in unexpected places. This allowed for malicious placement of crafted messages.

By feeding a crafted input to "git apply", a path outside the working tree can be overwritten as the user who is running "git apply".

Using a specially-crafted repository, Git can be tricked into using its local clone optimization even when using a non-local transport. Though Git will abort local clones whose source $GITDIR/objects directory contains symbolic links (c.f., CVE-2022-39253), the objects directory itself may still be a symbolic link.

These two may be combined to include arbitrary files based on known paths on the victim's filesystem within the malicious repository's working copy, allowing for data exfiltration in a similar manner as CVE-2022-39253.

Git is distributed revision control system. git log can display commits in an arbitrary format using its --format specifiers. This functionality is also exposed to git archive via the export-subst gitattribute. When processing the padding operators, there is a 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 git archive via the export-subst mechanism, which expands format specifiers inside of files within the repository during a git archive. This integer overflow can result in arbitrary heap writes, which may result in arbitrary code execution. The problem has been patched in the versions published on 2023-01-17, going back to v2.30.7. Users are advised to upgrade. Users who are unable to upgrade should disable git archive in untrusted repositories. If you expose git archive via git daemon, disable it by running git config --global daemon.uploadArch false.

https://github.com/git/git/security/advisories/GHSA-475x-2q3q-hvwq https://github.com/git/git/commit/508386c6c5857b4faa2c3e491f422c98cc69ae76 https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#exportsubst https://git-scm.com/docs/pretty-formats#Documentation/pretty-formats.txt-emltltNgttruncltruncmtruncem

Git is distributed revision control system. gitattributes are a mechanism to allow defining attributes for paths. These attributes can be defined by adding a .gitattributes file to the repository, which contains a set of file patterns and the attributes that should be set for paths matching this pattern. When parsing gitattributes, multiple integer overflows can occur when there is a huge number of path patterns, a huge number of attributes for a single pattern, or when the declared attribute names are huge. 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 result in remote code execution. The problem has been patched in the versions published on 2023-01-17, going back to v2.30.7. Users are advised to upgrade. There are no known workarounds for this issue.

https://github.com/git/git/security/advisories/GHSA-c738-c5qq-xg89 https://github.com/git/git/commit/508386c6c5857b4faa2c3e491f422c98cc69ae76