Description
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.
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.
Analysis
Analysis and contextual insights are available on OpenCVE Cloud.
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Git | Git | unaffected |
|
No data.
No data.
No data available yet.
Remediation
Vendor Solution
Upgrade to versions 2.50.2, 2.51.3, 2.52.1, 2.53.1, 2.54.1, 2.55.1, 2.56.1 or above.
Tracking
Sign in to view the affected projects.
Advisories
No advisories yet.
References
History
Tue, 10 Nov 2026 18:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | Heap-based Buffer Overflow in Git | |
| First Time appeared |
Git-scm
Git-scm git |
|
| Weaknesses | CWE-122 | |
| CPEs | cpe:2.3:a:git-scm:git:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Git-scm
Git-scm git |
|
| References |
| |
| Metrics |
cvssV3_1
|
MITRE
Status: PUBLISHED
Assigner: GitLab
Published:
Updated: 2026-11-10T18:34:09.369Z
Reserved: 2026-10-05T13:05:02.346Z
Link: CVE-2026-105437
Vulnrichment
No data.
NVD
Status : Received
Published: 2026-11-10T19:17:46.200
Modified: 2026-11-10T19:17:46.200
Link: CVE-2026-105437
Redhat
No data.
OpenCVE Enrichment
No data.
Weaknesses
-
CWE-122
Heap-based Buffer Overflow