your newest Gitea contributor might already have a shell on your server

Gitea shipped version 1.27.1 on July 27, fixing a 9.8-severity remote code execution bug that let anyone with plain repository write access — the exact permission level Gitea hands to any account it lets self-register — turn a crafted patch into a live git hook and run shell commands as the Gitea service account. No admin rights needed. And the advisory that disclosed it arrived with working proof-of-concept code already attached.

How a diff turns into a shell

Here's the mechanism, stripped of jargon. Gitea's diffpatch endpoint applies uploaded patches to a temporary clone of a repository so it can preview a merge. Submit the same crafted patch twice and you force an add/add collision — two versions of the same new file colliding during a three-way merge. Git's fallback for that collision checks out both candidate files into the working tree, and because the temporary clone is bare, its working-tree root doubles as Git's own hook directory. Land a file at hooks/post-index-change there, and it becomes an executable hook that fires the next time the index updates — running with whatever privileges the Gitea service account has, not the attacker's.

1. Attacker with ordinary repo write access calls POST /api/v1/repos/{owner}/{repo}/diffpatch
2. The same malicious patch is submitted twice, forcing an add/add merge collision
3. Git's three-way fallback checks out hooks/post-index-change into the bare clone's root ($GIT_DIR)
4. The hook fires on the next index update, executing as the Gitea service account

Who's actually exposed

This hits self-hosted Gitea instances specifically — the kind small teams and open-source projects spin up because they don't want their code on someone else's cloud. The part that makes it worse than a typical privilege-escalation bug: Gitea enables public self-registration by default. An attacker doesn't need to compromise an existing account or wait for an insider threat. They can visit an unmodified installation, register a normal account, create a repository, and exploit the bug with credentials they issued to themselves thirty seconds earlier.

This keeps happening to self-hosted dev tools

Gitea isn't an outlier this year, it's a pattern. An upload-processing endpoint was also the root cause behind Rails Active Storage's file-type spoofing bug, and unpatched internal tooling is exactly why ServiceNow's pre-auth RCE was still being actively exploited months after the fix shipped. Add the Fastjson library that went unpatched for years before this one finally landed and vBulletin's own pre-auth RCE going public a month after its quiet fix, and the throughline is obvious: the tools developers install for themselves get patched far slower than the SaaS products IT departments track centrally.

Gitea's own advisory feed is worth watching directly if you run any self-hosted instance — this is the kind of bug that gets rediscovered by opportunists for months after the headlines move on. And zoom out: Microsoft's own record-setting 569-CVE Patch Tuesday this year is the broader evidence that patch volume across the entire industry is climbing faster than most teams' triage capacity — which is exactly why a 9.8 needing zero privileges shouldn't sit in a normal patch-cycle queue.