Git powers the collaborative workflow of millions, keeping source code in sync across teams and continents. But deep in its handling of submodules lies a recent, under-discussed bug—CVE-2023-29007—that could hand attackers control of your system, simply by making you run a normal Git command on an infected repository.

This exclusive deep-dive explains what happened, how it works, and how you can keep your development environment safe.

What Is CVE-2023-29007?

CVE-2023-29007 is a serious vulnerability found in Git prior to patched versions like 2.30.9 and up. The problem centers around how Git processes the .gitmodules file—especially if it contains very long submodule URLs (longer than 1024 characters).

The bug can let attackers inject malicious configuration into your local .git/config just by getting you to run certain Git commands (like git submodule deinit). If they inject config values specifying commands to run (think: core.pager, core.editor, etc.), the next time you perform routine actions, Git might run attacker-chosen code on your machine.

Here’s what makes this issue particularly sneaky

- No compile-time exploits required. Just interacting with a repo—with typical commands—can trigger the bug.

The Technical Breakdown (How Does It Work?)

At its heart, the bug lies in an unsafe assumption about how config sections get copied or renamed during certain Git operations. Specifically, in the C function git_config_copy_or_rename_section_in_file() inside config.c.

The .gitmodules file tracks submodules in a project. It can contain entries like

[submodule "external"]
    path = lib/external
    url = https://example.com/external-repo.git

Nothing suspicious there. But an attacker can craft a section where the url value is crazy long (over 1024 characters), and, due to a bug in how Git parses these chunks, sneak in extra configuration under the radar.

Malicious .gitmodules example

[submodule "mal"]
    path = evil
    url = aaaaaaaaa....(1024+ chars)...aaaaa
    [core]
        editor = /tmp/evil_script.sh

When you later run git submodule deinit --all (or a related submodule command) on this repo, Git may misinterpret the section boundaries. Without correct boundaries, the [core] section inside the attacker's .gitmodules gets copied into your main Git config.

Or any command that internally triggers config copying.

4. Git misparses the long config and “injects” attacker’s [core] editor=... or similar into victim's .git/config.

Demonstration Snippet

Below is a conceptual payload for .gitmodules. (Do NOT test on a production machine!)

[submodule "attack"]
    path = pwned
    url = https://example.com/$(touch /tmp/gotyou)
    [core]
        editor = /tmp/gotyou.sh

Assuming /tmp/gotyou.sh exists and is executable, this script will run whenever the victim performs an edit involving Git (git commit, etc.), after the inject.

References and Further Reading

- GitHub Advisory GHSA-2j86-f273-x4gw
- NVD Entry: CVE-2023-29007
- Git 2.41 Release Notes (includes this fix)

2.41 and newer

Run git --version to check your current version. Download latest Git for your OS.

As a workaround:  
- Never run git submodule deinit, or similar submodule commands, on repos from untrusted sources.
- Check .gitmodules and .git/config for unexpected sections before running any submodule-related commands.

Cleaning your config:  
If you think you may have been affected, open .git/config and scan for suspicious entries (especially core.editor, core.pager, core.sshCommand pointing to odd scripts or binaries).

Conclusion

The CVE-2023-29007 bug is a powerful reminder that even trusted tools like Git can contain subtle, dangerous flaws—sometimes hidden in features that most of us rarely inspect.

Stay alert. Keep your software up-to-date. And always treat repositories from unknown sources as potentially hostile until proven otherwise.

If you want more details or demos, check the official GitHub security advisory.

Timeline

Published on: 04/25/2023 21:15:00 UTC
Last modified on: 05/04/2023 21:19:00 UTC