Git Disaster Recovery - When Everything Goes Wrong

IMMEDIATE ACTION REQUIRED if you're on Linux or macOS. CVE-2025-48384 allows arbitrary code execution when cloning repositories with malicious submodules. This vulnerability is actively being exploited and was added to CISA's Known Exploited Vulnerabilities catalog.

Update Git immediately - versions before these are vulnerable:

• Git 2.45.4 (patched version)
• Git 2.44.4
• Git 2.43.7

If you're the type who clones random GitHub repos without thinking, you're fucked. The exploit works through crafted `.gitmodules` files that use carriage return characters to bypass security checks. When you run git clone --recursive, malicious submodules can write arbitrary files to your system. Proof-of-concept code is publicly available, making this a high-priority patch.

Windows users are not affected by this specific vulnerability due to different path handling.

Repository Corruption Recovery

Power outages, filesystem corruption, and hardware failures can destroy Git repositories. Here's how to recover when .git/ becomes unreadable:

Step 1: Assess the Damage

git fsck --full --no-reflogs --no-progress

This scans every object in the repository and reports corruption. Common errors:

• error: bad object - corrupted blob/tree/commit objects
• error: refs/heads/main does not point to a valid object - branch pointer corruption
• fatal: loose object is corrupt - individual file corruption

Step 2: Salvage What You Can

If you have any working clones (teammates, CI servers, your laptop backup), start there:

## Clone from any available source
git clone https://github.com/torvalds/linux.git recovery-attempt
cd recovery-attempt

## Fetch all refs to get complete history
git fetch --all
git fetch --tags

Step 3: Reconstruct from Fragments

For severe corruption, use Git's recovery tools:

## Find all recoverable commits
git fsck --lost-found

## List unreachable commits
git fsck --unreachable

## Show commit content to identify useful ones
git show <commit-hash>

## Create new branch from recovered commit
git branch recovery-branch <commit-hash>

Did this during a major release when everything was on fire and the demo was in 20 minutes. Lost two days of work but recovered the core functionality by piecing together commits from the reflog.

Accidental Force Push Recovery

Someone force-pushed to main and nuked a week of team commits. Here's the emergency procedure:

If You Have Local Copies

## Check your reflog for the lost commits
git reflog --all | grep "main"

## Find the last good state
git log --oneline -10 origin/main

## Force push the recovery (communicate with team first!)
git push origin <good-commit-hash>:main --force-with-lease

If Remote is Your Only Copy

Check if your Git hosting provider has backup policies:

• GitHub: No automatic backups, but contact support immediately
• GitLab: 24-hour backup retention on paid plans
• Bitbucket: Limited backup options, mostly manual recovery

This saved us from a production outage at 3am on Black Friday when a junior dev force-pushed a broken main branch.

Lost Branch Recovery

Deleted a feature branch with weeks of work? Git keeps orphaned commits for 30 days:

## Search reflog for the deleted branch
git reflog --all | grep "branch-name"

## Or search by commit message
git log --all --grep="specific commit message"

## Recreate the branch
git branch recovered-branch <commit-hash>

## Verify the recovery
git log --oneline recovered-branch

The reflog is append-only and survives most disasters. It's your last line of defense against stupidity. For additional recovery techniques, check the official Git recovery documentation and Stack Overflow's Git disaster recovery tag.