That Time Someone Exploited a Git Hook to Root Your Homelab You know how it is—you spin up a self-hosted Git instance, maybe Forgejo or Gitea, and you're feeling good about having your own GitHub alternative. Then you forget about it for a while. That's usually when something bad happens. Someone just posted a writeup about waking up to Pushover alerts because their i5-10600K was pinned at 50% CPU for 24 hours straight. The investigation turned into a reverse-engineering rabbit hole that's worth reading if you run any self-hosted Git services. 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: What version are you on? Check if it's EOL. If it is, update now. Not "soon," not "this weekend," now. 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. 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. 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