EUVD-2026-41620
GHSA-47rq-xp99-92mx
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate to Gitea with limited access
-
DeliveryTarget an eligible GitHub-style pull request
-
ExploitInvoke update/rebase branch action
-
ExecutionBypass insufficient head-branch permission check
-
PersistPush or rewrite commits on protected head branch
-
ImpactTamper with PR code integrity
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Access control enforcement
MITRE ATT&CK
1 technique across 1 tactic: Defense Evasion The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires the Gitea pull-request unit to be enabled on the base repository and a GitHub-style (non-AGit) pull request to exist; the actor interacts with the PR's update/rebase feature. Exploitation is limited by the fact that the user must be authenticated to Gitea and able to reach the pull request, and the maintainer-edit inheritance path only applies when the PR author enabled 'Allow maintainers to edit'; AGit-flow pull requests are not affected. Note a signal conflict: the NVD vector states PR:N (unauthenticated), but the patched code operates on an authenticated user object, so an account with some repository/PR access is the realistic prerequisite - authentication requirements not fully confirmed from available data. |
| Impact | Signals are mixed and lean toward a moderate, not urgent, priority. The NVD CVSS vector (AV:N/AC:L/PR:N/UI:N, 7.5) presents this as network-exploitable with no privileges, but that conflicts with the nature of the flaw and the patched code, which operates on an authenticated user object interacting with a pull request - realistically an attacker needs a Gitea account with some access to the repository/PR, so PR:N likely overstates the ease of exploitation; verify auth expectations with the vendor. Impact is integrity-only (I:H; C:N/A:N): an attacker can alter branch contents/history but cannot read secrets or take the service down. SSVC reinforces the low-urgency read (Exploitation: none, Technical Impact: partial) despite Automatable: yes, and EPSS is very low (0.16%, 5th percentile). It is not in CISA KEV and no public exploit identified at time of analysis. Net: a legitimate access-control bug worth patching on the normal cycle, but not a drop-everything emergency; the 'unauthenticated' framing appears inflated relative to the code evidence. |
| Exploit ScenarioDerived | An attacker with a Gitea account and limited access to a repository opens or targets a pull request and invokes the 'Update branch' (merge or rebase) action, which pre-1.25.5 fails to properly verify their push/force-push rights on the head branch. As a result they push base-branch commits into - or rebase and rewrite the history of - a head branch they should not be permitted to modify, tampering with proposed code before review or merge. No public exploit identified at time of analysis, but the logic is straightforward to trigger through the normal PR UI/API. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jul 22, 2026
Improper access control in Gitea before 1.25.5 allows users to update or rebase pull request head branches without holding the write/force-push permissions those actions require, letting them push base-branch commits or rewrite history on branches they should not control. The flaw stems from the IsUserAllowedToUpdate logic in services/pull/update.go, which failed to properly re-check repository push and branch-protection permissions on the head branch. This is an integrity-only issue (CVSS 7.5, I:H) with no confidentiality or availability impact; SSVC lists exploitation as none and EPSS is low (0.16%), and no public exploit identified at time of analysis.
RemediationAI
Vendor-released patch: 1.25.5 - upgrade all Gitea instances to 1.25.5 or later, which refactors the pull-request update/rebase permission check to properly validate head-repository push permission and branch-protection force-push rules (see https://github.com/go-gitea/gitea/releases/tag/v1.25.5 and https://blog.gitea.com/release-of-1.25.5/). If immediate upgrade is not possible, reduce exposure by tightening who can interact with pull requests: enforce branch protection on head/fork branches, restrict repository write and force-push whitelists to trusted maintainers, and disable 'Allow maintainers to edit' (AllowMaintainerEdit) on sensitive pull requests where inherited permissions are a concern - noting these controls limit collaboration workflows and do not fully close the underlying access-control gap. Monitor repository push and PR-update activity for unexpected branch updates until patched.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in go, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Gitea is a self-hosted, lightweight open-source Git service (the CPE cpe:2.3:a:gitea:gitea_open_source_git_server) providing repository hosting, pull requests, and branch protection. The root cause is CWE-284 (Improper Access Control): the pull-request 'Update by rebase/merge' feature computes whether a user may push new commits to the PR head branch, but the pre-1.25.5 IsUserAllowedToUpdate function did not correctly enforce push permission and branch-protection force-push rules on the head repository/branch. The upstream fix (PR 36465, refined by PR 36838) refactors the check into a dedicated isUserAllowedToPushOrForcePushInRepoBranch helper that evaluates both repository write permission (CanWrite on the code unit) and any matching protected-branch rule (CanUserPush/CanUserForcePush), and only inherits the PR poster's permissions when AllowMaintainerEdit is set and the user is a legitimate maintainer able to merge the PR.
Know when Gitea gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Network-reachable PR feature with low complexity, but requires an authenticated account able to reach the pull request (PR:L not PR:N); impact is integrity-only, so C:N/A:N and I:H.
Primary rating from Vendor (Gitea).
CVSS VectorVendor: Gitea
Lifecycle Timeline
2DescriptionCVE.org
Gitea versions before 1.25.5 have insufficient permission checks for updating or rebasing pull request branches.
Executive ViewAI
Gitea versions prior to 1.25.5 contain an access control flaw allowing users to bypass branch protection and modify pull requests without proper authorization, creating significant code integrity and supply chain risks for organizations using affected versions.
Apply vendor patch: Gitea 1.25.5.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Remote code execution in Gitea (self-hosted Git service) via a code-injection flaw (CWE-94) allows attackers to run arbi
Broken access control in Gitea's Composer package registry (versions up to and including 1.26.1) lets remote attackers r
Gitea before 1.16.7 does not escape git fetch remote. Rated high severity (CVSS 7.5), this vulnerability is remotely exp
The git hook feature in Gitea 1.1.0 through 1.12.5 might allow for authenticated remote code execution in customer envir
Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Gitea Gitea
Reverse-proxy authentication bypass in the official Gitea Docker image (versions up to and including 1.26.2) allows any
Path traversal in Gitea's Org-mode (`.org`) markup renderer allows an attacker who can get Org-mode content rendered by
Container escape in Gitea act_runner (Docker backend, through act 0.262.0) lets an authenticated user with workflow-exec
models/repo_mirror.go in Gitea before 1.7.6 and 1.8.x before 1.8-RC3 mishandles mirror repo URL settings, leading to rem
Server-side request forgery and internal repository exfiltration in Gitea before 1.27.0 lets a low-privileged authentica
Authorization bypass in Gitea versions 1.22.3 through 1.26.1 allows holders of `public-only` access tokens or OAuth gran
An issue was discovered in Gitea through 1.11.5. Rated high severity (CVSS 7.5), this vulnerability is remotely exploita
Exploit-DB