CVE-2022-23521 - Critical Integer Overflow in Git gitattributes File Parsing Exposes Remote Code Execution Risk

Git is the world’s leading distributed version control system, used everywhere from open-source projects to the largest enterprise codebases. Part of Git’s flexibility comes from .gitattributes, a powerful tool for configuring handling of files and paths in your repository. But, as discovered in late 2022, this flexibility also introduced a dangerous integer overflow vulnerability—CVE-2022-23521—that can be triggered with a maliciously crafted .gitattributes file.

This exclusive long read explains exactly what happened, how it works under the hood, sample code to understand the vulnerability, and how to keep yourself safe. Whether you’re a developer, a security professional, or just curious, this guide will help you make sense of a complex but serious Git security issue.

What is .gitattributes?

.gitattributes files allow you to assign particular attributes or rules to certain paths or file patterns inside your repo. Here’s a classic example:

# .gitattributes example
*.jpg     binary
*.txt     text
*.sh      eol=lf
/docs/*   diff

These rules can be used to define behavior for line endings, diff drivers, filters, and more, offering fine-grained control over how files are handled by Git.

The Vulnerability: Integer Overflow When Parsing

The trouble starts when Git *parses* these .gitattributes files. The parser tries to be smart about splitting lines, keeping track of attribute names, and applying rules to the right files. But in versions before January 17, 2023, three particular things could trigger an integer overflow:

One or more attribute names that are excessively long

When combined in a malicious .gitattributes file, these factors can make the underlying C code in Git compute an array size or allocation length that “wraps around” past the max allowed value, leading to memory reads and writes outside the intended area. This is a classic scenario for enabling remote code execution.

Practical Exploit Scenario

If an attacker can get a malicious .gitattributes file into a repository—*for example, via a pull request or as part of a submodule*—and convince a victim to check out or process that repo, they can exploit this bug.

Here's a simplified proof-of-concept snippet adapted from the reported analysis

# .gitattributes (malicious)
*.verylongpathextension[...repeats tens of thousands of times...]  attr1 attr2 attr3 ... attrN

By designing this file to exceed certain size thresholds (especially for attribute names and number of attributes), the attacker triggers the internal overflow.

Key detail: *Git splits lines longer than 2KB when parsing from a file but not from the index*, meaning that how this bug is triggered can depend on whether the file is in your working tree, index, or both. In the wrong circumstance, Git's in-memory computation can be corrupted.

Here's a theoretical (Python-style pseudo) example of how an attacker might generate a dangerous file:

# Generates a .gitattributes file with one huge line
with open(".gitattributes", "w") as f:
    pattern = "*.malicious "
    attributes = " ".join(f"attr{i}" for i in range(100000))
    f.write(pattern + attributes + "\n")

If you try to git add and commit this file—or even just check out a repo containing it—you might trigger memory corruption under affected Git versions.

Arbitrary heap reads and writes

When memory allocation sizes are calculated wrong, data can be read from or written outside the intended buffer. This can lead to all sorts of unpredictable behavior.

Remote Code Execution (RCE)

With clever design, these overflows can potentially allow attackers to execute arbitrary code on your machine when you interact with the repo or run certain Git commands.

Who is Affected?

- All Git users prior to v2.39.1, v2.38.3, v2.37.7, v2.36.6, v2.35.6, v2.34.6, v2.33.7, v2.32.8, v2.31.7, and v2.30.7

Is There a Workaround?

No. There is no known workaround short of upgrading your Git client.

Is This Really Exploitable?

Yes. The flaw allows remote execution. The attacker does not need to have local access; it’s enough to get you to interact with their repo containing a malicious .gitattributes. This could even impact automated build or CI systems.

How Do I Fix It?

Upgrade your Git installation!
Fixes for CVE-2022-23521 were released on January 17, 2023.
All major package managers and distributions quickly pushed updates.

You can check your current Git version with

git --version

And upgrade as follows

- Debian/Ubuntu:

sudo apt install git

- macOS (Homebrew):

brew upgrade git

 - Windows: Download the latest installer from Git for Windows --- ## References and Further Reading - Original GitHub Security Advisory - CVE-2022-23521 at NIST NVD - Git Release Notes with Patch - Official Git download site --- ## Summary Table | Detail | Info | |-----------------|--------------------------------------------------------------------------------| | CVE ID | CVE-2022-23521 | | Affected Git | Prior to 2.39.1, see above for more detail | | Discovered | Late 2022, publicly patched Jan 17, 2023 | | Attack Vector | Malicious .gitattributes` file in repository commit history |
| Impact | Memory corruption, arbitrary code execution |
| Fix | Upgrade Git to fixed version |
| Workaround | None |

---

## Final Word

If you use Git even occasionally—or run systems that automatically fetch and process remote repositories—you *must* upgrade to a safe version. While few real-world attacks have been reported (so far), this bug is a perfect example of how complex parsers for config files can introduce low-level, high-impact vulnerabilities in tools we all rely on.

Stay safe, keep your tools patched, and remain alert as the software supply chain becomes a bigger target.

---

*Written exclusively for you with simple, clear language. If you found this valuable, share and help keep your fellow developers secure!*

---

If you have more questions about CVE-2022-23521 or Git security, drop them below!

Timeline

Published on: 01/17/2023 23:15:00 UTC
Last modified on: 01/26/2023 13:51:00 UTC