Gitea: Authorization Bypass via "Allow edits from maintainers" allows unauthorized commits to any readable repo
Description
Authenticated read-only users can push arbitrary commits to any readable Gitea repository by abusing the 'Allow edits from maintainers' PR feature.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Authenticated read-only users can push arbitrary commits to any readable Gitea repository by abusing the 'Allow edits from maintainers' PR feature.
Vulnerability
The vulnerability exists in Gitea versions <=1.26.1. The "Allow edits from maintainers" PR option can be abused via reverse-fork PRs. The web UI PR-create endpoint binds allow_maintainer_edit=true without verifying that the submitter has write access to the HEAD repository. This allows an attacker to create a PR where BASE is their own fork and HEAD is the upstream target. On git push over HTTP/SSH, Gitea relaxes access mode to Read when SupportProcReceive is enabled, deferring enforcement to the pre-receive hook. The hook calls CanMaintainerWriteToBranch, which finds the malicious PR with AllowMaintainerEdit=true and checks write access on the BASE repo (attacker's fork), passing the check and authorizing the push against the upstream [1][2].
Exploitation
An attacker must have an authenticated low-privilege account with at least read access to the target repository. First, they fork the target repository. Then they visit the web compare endpoint and create a PR with BASE = their fork, HEAD = upstream, and the "Allow edits from maintainers" option checked. Finally, they clone their fork, make a commit, and run git push <upstream_url> – the push is accepted without write permissions [1][2].
Impact
A successful exploit allows an attacker to push arbitrary commits directly to any repository they have read access to, bypassing all write-access checks. This compromises the integrity of the repository and can lead to unauthorized code changes, backdoors, or data corruption. The attacker gains the ability to write to the repository as if they had maintainer privileges [1][2].
Mitigation
Gitea has addressed this issue in version 1.26.2 (or later). Users should upgrade to the latest patched version. As a workaround, administrators can disable the "Allow edits from maintainers" feature or restrict repository read access. No other mitigations are mentioned in the available references [1][2].
AI Insight generated on Jun 16, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
1Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"The PR-create endpoint sets `allow_maintainer_edit=true` without verifying the submitter has write access to the HEAD repository, and the `CanMaintainerWriteToBranch` function checks write access against the BASE repo instead of the HEAD repo, allowing an attacker to push arbitrary commits to the upstream repository."
Attack vector
An attacker forks the target repository, then creates a pull request with BASE set to their own fork and HEAD set to the upstream target, checking the "Allow edits from maintainers" option. Because the attacker is the maintainer of the BASE (their own fork), the `AllowMaintainerEdit` flag is set against the upstream HEAD without verifying the attacker has write access to the HEAD repository [ref_id=1][ref_id=2]. When the attacker pushes over HTTP/SSH, Gitea relaxes the required access mode to `Read` and defers enforcement to the pre-receive hook, which calls `CanMaintainerWriteToBranch`. That function finds the malicious PR, sees `AllowMaintainerEdit=true`, and checks write access against the BASE repo (the attacker's own fork), so the check passes and the push is authorized against the upstream [ref_id=1][ref_id=2].
Affected code
The vulnerability involves the PR-create endpoint which sets `allow_maintainer_edit=true` without verifying write access to the HEAD repository, and the `CanMaintainerWriteToBranch` function in `models/issues/pull_list.go` which checks write access against the BASE repo instead of the HEAD repo. The push authorization path in `routers/web/repo/githttp.go` and `routers/private/serv.go` relaxes the required access mode to `Read` when `SupportProcReceive` is enabled, deferring enforcement to the pre-receive hook.
What the fix does
The advisory recommends two independent fixes for defense in depth [ref_id=2]. First, at PR creation time, before setting `AllowMaintainerEdit = true`, the system should verify that the submitter has write access to the HEAD repository. Second, in the `CanMaintainerWriteToBranch` function, the code should verify that the PR's HEAD repo matches the repository being pushed to, and that the PR was opened by a legitimate owner or writer of the HEAD repository, rather than trusting `AllowMaintainerEdit` solely based on BASE write access.
Preconditions
- authThe attacker must be an authenticated user with at least read access to the target repository
- inputThe attacker must be able to fork the target repository and create a pull request
- configThe Gitea instance must have SupportProcReceive enabled (default in many configurations)
Reproduction
```bash python3 poc.py --repo http://gitea:3000/victim/repo --user attacker --password attacker_pass ``` [poc.py](https://github.com/user-attachments/files/26641541/poc.py)
Expected output: ``` [+] target: victim/my_repo default branch: main [*] forking -> attacker/my_repo_pocfork (202) [+] fork ready [+] malicious PR created (BASE=attacker fork, HEAD=upstream)
remote: . Processing 1 references remote: Processed 1 references in total To http://192.168.101.20:3000/victim/my_repo.git e5c07b3..9a0b884 main -> main
[+] latest commit on victim/my_repo@main: 'PoC: unauthorized commit via maintainer-edit bypass' [+] CONFIRMED: unauthorized push to upstream succeeded. ``` A `PWNED.txt` file will appear on the target repo's default branch, committed by the attacker who has no write access.
Generated on Jun 16, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
2News mentions
0No linked articles in our index yet.