That Time Someone Exploited a Git Hook to Root Your Homelab

What Actually Happened

The short version: they were running Forgejo v13, which hit end-of-life in January 2026. They had open signup enabled (mistake #1). An attacker registered, poked around, and found CVE-2026-60004-a vulnerability in the Gitea diffpatch endpoint that lets you write arbitrary files to the repository. The attacker used it to drop a malicious post-index-change Git hook.

If you're not familiar with Git hooks, they're scripts that run at various points in the Git workflow-pre-commit, post-merge, and so on. They're incredibly useful, and also incredibly dangerous if you don't control who can write them.

The Payload Was Thorough

The hook didn't just do one thing. It:

• Killed any processes with "guard" in the name (probably monitoring or security tools)
• Disabled systemd units for competing CPU-intensive workloads (to free up resources for the attacker's binaries)
• Downloaded architecture-specific binaries using six different fallback methods (curl, wget, Python, etc.)

Six fallback download methods. That's not a script kiddie-someone planned this.

The Painful Part

The author admits they should have been reading the release notes. Forgejo v13 was EOL since January 2026, and CVE-2026-60004 was patched in newer versions. But let's be honest-how many of us actually read release notes for every self-hosted service we run? We update when something breaks, not when there's a security fix.

The other issue: open signup on a self-hosted Git instance. If you're running this for a team, fine. If you're running it for yourself, why is anyone else allowed to register? There's usually a config flag to disable public registration. Use it.

What to Check

If you're running Forgejo, Gitea, or any self-hosted Git platform:

1. What version are you on? Check if it's EOL. If it is, update now. Not "soon," not "this weekend," now.
2. Is signup open? If you don't need it, disable it. There's no reason to let random people create accounts on your personal Git server.
3. Can users write Git hooks? This is the critical one. Git hooks are powerful-they run with the same privileges as the Git server process. If an attacker can write a hook, they own your system. Lock this down in the config.
4. Are you monitoring CPU/disk/network? The author only caught this because of sustained high CPU. Basic monitoring would have flagged this earlier.

The Broader Lesson

Self-hosted services are great until they're not. The moment you deploy something, you're responsible for keeping it updated, securing it, and monitoring it. There's no team of engineers at GitHub doing this for you. If you can't commit to that, use the hosted version. If you can, at least read the release notes.

Schiff Heimlich | Still updating things I forgot about