Vulnerability Database

352,427

Total vulnerabilities in the database

CVE-2026-26231 — code.gitea.io/gitea

Incorrect Authorization

Summary

Any authenticated low-privilege user with read access to a repository can push arbitrary commits directly to that repository, bypassing all write-access checks.

Vulnerability

Gitea's "Allow edits from maintainers" PR option can be abused via reverse-fork PRs:

  1. The web UI PR-create endpoint binds allow_maintainer_edit=true without verifying that the submitter has write access to the HEAD repository.
  2. Gitea allows creating a PR where BASE = attacker's fork and HEAD = upstream target. The attacker is "maintainer" of the BASE (their own fork), so the flag is set against the upstream HEAD.
  3. On git push over HTTP/SSH, Gitea relaxes the required access mode to Read when SupportProcReceive is enabled (routers/web/repo/githttp.go, routers/private/serv.go) and defers enforcement to the pre-receive hook.
  4. The pre-receive hook calls CanMaintainerWriteToBranch (models/issues/pull_list.go), which finds the malicious PR, sees AllowMaintainerEdit=true, and checks whether the pusher has write access to the BASE repo. Since BASE is the attacker's own fork, the check passes and the push is authorized against the upstream.

Exploitation

  1. Attacker forks the target repository.
  2. Attacker visits the web compare endpoint and creates a PR with BASE = their_fork, HEAD = upstream, and "Allow edits from maintainers" checked.
  3. Attacker clones their fork, makes a commit, and runs git push <upstream_url> <branch> — the push is accepted.

Reproduction

python3 poc.py --repo http://gitea:3000/victim/repo --user attacker --password attacker_pass

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.

Impact

Full repository compromise. Any logged-in user can backdoor any repository they can read, including all public repositories on the instance.

Suggested Fix

Two independent checks are missing; both should be added for defense in depth:

  1. At PR creation: before setting AllowMaintainerEdit = true, verify the submitter has write access to the HEAD repository.
  2. In CanMaintainerWriteToBranch: verify that the PR's HEAD repo matches the repository being pushed to, and that the PR was opened by a legitimate owner/writer of the HEAD repository. Do not trust AllowMaintainerEdit solely based on BASE write access.

CVSS v3:

  • Severity: High
  • Score: 8.5
  • AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N

CWEs:

Frequently Asked Questions

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.