Git up to 2.56.0 heap-based overflow

Summaryinfo

A vulnerability identified as critical has been detected in Git up to 2.56.0. Affected by this issue is some unknown functionality. This manipulation causes heap-based overflow. The identification of this vulnerability is CVE-2026-105437. It is possible to initiate the attack remotely. There is no exploit available. You should upgrade the affected component.

Detailsinfo

A vulnerability was found in Git up to 2.56.0. It has been declared as critical. Affected by this vulnerability is some unknown functionality. The manipulation with an unknown input leads to a heap-based overflow vulnerability. The CWE definition for the vulnerability is CWE-122. The product writes past the end of a buffer that was allocated on the heap. As an impact it is known to affect confidentiality, integrity, and availability. The summary by CVE is:

Affected versions of Git have a heap buffer overflow in the three-way merge code (xdiff), which an attacker can trigger through a repository they control. When Git merges a file, it first adds up the size of the merged output, allocates a buffer of that size, and then writes the output into it. That total was kept in a 32-bit signed integer. The conflict-marker-size attribute, which can be set from a committed .gitattributes file, accepts any positive integer, and the markers are written several times for every conflict. A small file with a huge marker size and many separate conflicts can therefore push the total past 4 GiB, so the integer wraps to a small value and Git writes attacker-controlled merge output past the end of a buffer that is too small. At minimum this crashes Git, and because the overflow is large and its contents are largely attacker-controlled, worse heap corruption is possible. Any command that does a textual three-way merge can trigger it, such as git-merge(1), git-rebase(1), git-cherry-pick(1), and git-merge-tree(1). The latter is most likely a target for Git forges, which might use git-merge-tree(1) on the server-side to check mergeability. When the server reads attributes from trees in the repository (for example through attr.tree or --attr-source), any user who can push branches and request that they be merged (for example by opening a pull or merge request) can trigger the overflow without anyone else doing anything, and the data they push is small because the oversized output only appears during the merge. The problem has been patched by computing the size as size_t and checking every addition for overflow, so Git stops with an error instead of overflowing. Servers that cannot upgrade right away can add * conflict-marker-size=7 to each repository's info/attributes as a workaround, which overrides any in-tree .gitattributes, or turn off server-side mergeability checks for untrusted repositories.

The advisory is shared at gitlab.com. This vulnerability is known as CVE-2026-105437 since 10/05/2026. The exploitation appears to be easy. The attack can be launched remotely. Neither technical details nor an exploit are publicly available.

Upgrading to version 2.49.1, 2.50.2, 2.51.3, 2.52.1, 2.53.1, 2.54.1, 2.55.1 or 2.56.1 eliminates this vulnerability.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Productinfo

Type

• Versioning Software

Name

• Git

Version

• 2.0
• 2.1
• 2.2
• 2.3
• 2.4
• 2.5
• 2.6
• 2.7
• 2.8
• 2.9
• 2.10
• 2.11
• 2.12
• 2.13
• 2.14
• 2.15
• 2.16
• 2.17
• 2.18
• 2.19
• 2.20
• 2.21
• 2.22
• 2.23
• 2.24
• 2.25
• 2.26
• 2.27
• 2.28
• 2.29
• 2.30
• 2.31
• 2.32
• 2.33
• 2.34
• 2.35
• 2.36
• 2.37
• 2.38
• 2.39
• 2.40
• 2.41
• 2.42
• 2.43
• 2.44
• 2.45
• 2.46
• 2.47
• 2.48
• 2.49
• 2.49.0
• 2.50
• 2.50.0
• 2.50.1
• 2.51
• 2.51.0
• 2.51.1
• 2.51.2
• 2.52
• 2.52.0
• 2.53
• 2.53.0
• 2.54
• 2.54.0
• 2.55
• 2.55.0
• 2.56.0

License

• open-source

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Discussion