Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as repository administrator
-
DeliveryCall push-mirror API with local filesystem path
-
ExploitOwner permission checked instead of caller
-
ExecutionGitea pushes refs into target path as Gitea process
-
ImpactOverwrite arbitrary server-side Git repository
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization logic validation
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires three concurrent conditions: (1) the instance is configured with [security] IMPORT_LOCAL_PATHS = true, which is NOT the default; (2) the attacker holds repository-administrator rights on a repository whose owner possesses the AllowImportLocal permission (the owner's permission is what the flawed check inspects); and (3) a writable existing Git repository resides at the chosen local filesystem path. Limiting factors that reduce realistic risk: the non-default IMPORT_LOCAL_PATHS setting, the need for authenticated repo-admin privileges, the dependency on the specific owner/caller permission mismatch, and the fact that writes occur only with the Gitea process's filesystem permissions. |
| Impact | This is a broken-access-control flaw (CWE-863) that scores CVSS 7.1 but carries meaningfully lower real-world risk than that number suggests, and the available signals are internally consistent on that point. EPSS is 0.15% (3rd percentile) and CISA SSVC records Exploitation: none and Automatable: no, matching the absence of any KEV listing or public exploit. SSVC Technical Impact is rated 'total,' consistent with the vendor's C:H/I:H, because a successful push can overwrite arbitrary server-side Git repositories. The dominant risk reducer is configuration dependence: exploitation is impossible unless the operator has explicitly enabled the non-default [security] IMPORT_LOCAL_PATHS = true, and even then the attacker must already hold repository-administrator rights on a repo whose owner is permitted to import local paths. One signal conflicts and should be verified with the vendor: the published vector uses AV:L (local), yet the vulnerable code path is the push-mirror REST API, which is reached over the network - the 'local' qualifier describes the target filesystem path, not the attacker's position, so network-reachability of the API likely makes true attack vector AV:N. Net assessment: a genuine privilege/authorization boundary bug worth patching on affected self-hosted instances that enable local-path import, but not an urgent mass-exploitation priority. |
| Exploit ScenarioDerived | On a Gitea instance running with IMPORT_LOCAL_PATHS enabled, a user who holds administrator rights over a repository - but who personally lacks the local-import permission - calls the push-mirror API and supplies a local filesystem path as the mirror target. Because Gitea validates the repository owner's permission instead of the caller's, the request is accepted, and Gitea pushes the repository's refs into an existing Git repository at that path using the Gitea process's own filesystem permissions. No public exploit code has been identified; the only published code is the upstream fix (PR 39501/39507). |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 07, 2026
Broken access control in Gitea's push-mirror API (CVE-2026-86684) lets an authenticated repository administrator push a repository's refs into an existing Git repository located on the server's local filesystem, using the permissions of the Gitea process rather than the caller's own privilege. Exploitation requires three conditions to hold simultaneously: the instance must be configured with [security] IMPORT_LOCAL_PATHS = true (not a default setting), the attacker must hold repository-administrator rights on a repository whose owner holds the AllowImportLocal permission (the owner's permission is what the flawed check inspected), and a writable Git repository must already exist at the chosen path. The integrity-only impact (CVSS 3.1 7.1, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N as independently assessed) and non-default prerequisites mean real-world risk is lower than the headline score implies; no public exploit code or confirmed active exploitation was identified at time of analysis, and EPSS is 0.15% (3rd percentile).
RemediationAI
Upgrade to Gitea 28.1.0 or later - vendor-released patch: Gitea 28.1.0, which changes the push-mirror authorization check from the repository owner (ctx.ContextUser) to the requesting user (ctx.Doer), per advisory GHSA-7v5j-mph8-9w6g and the release notes at https://blog.gitea.com/release-of-28.1.0/. If immediate upgrade is not possible, apply layered compensating controls and accept their trade-offs: first, set [security] IMPORT_LOCAL_PATHS = false in app.ini (this is the default) and restart Gitea - this fully removes the attack path but disables all legitimate local-path imports and migrations, including administrative workflows that depend on them; second, on patched or backported builds set [mirror] DISABLE_NEW_PUSH = true to block creation of new push mirrors entirely, at the cost of disabling a normal collaboration feature for all users; third, reduce the blast radius by auditing repository-admin grants so that only trusted users can administer repositories owned by accounts holding AllowImportLocal, and by reviewing repositories for stale or excessive AllowImportLocal grants; fourth, treat the Gitea process as a trust boundary - run it under a dedicated unprivileged OS account, ensure no writable Git repositories exist on paths that account can reach outside Gitea's own data directory, and use filesystem permissions or containers to wall off sensitive bare repositories, understanding that this restricts legitimate filesystem layout flexibility. Finally, audit existing push-mirror configurations for any remote addresses pointing to local filesystem paths and remove unexpected entries, since earlier exploitation would have written into those targets without generating new alerts.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw is CWE-863 (Incorrect Authorization) in Gitea's push-mirror creation path. The vulnerable handler, routers/api/v1/repo/mirror.go, called migrations.IsMigrateURLAllowed(address, ctx.ContextUser), passing the repository owner as the subject of the permission check instead of the authenticated caller (ctx.Doer). When [security] IMPORT_LOCAL_PATHS = true, Gitea permits local filesystem paths as migration/mirror targets - gated by the per-user AllowImportLocal permission. Because the check evaluated the owner rather than the requester, a repository administrator lacking AllowImportLocal could still register a local-path push mirror on a repository owned by a user who does have that permission. Gitea then executes the push with the privileges of the Gitea server process, writing refs into whatever Git repository already exists at that path. GitHub PR 39501 corrects this by switching the check to ctx.Doer and adds a test (TestCreatePushMirrorUsesCallerPermission) asserting unauthorized callers are rejected; the same change set also introduces an administrator kill switch via setting.Mirror.DisableNewPush in AddPushMirror, returning HTTP 403. The upstream commits are bundled with unrelated hardening elsewhere in the codebase, but the push-mirror authorization change is the fix for this CVE. Attack vector is network-reachable through the API (AV:N in our assessment; the original NVD vector claimed AV:L), requires authenticated repository-admin privileges (PR:L), and yields integrity impact only (I:H, C:N/A:N).
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:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Push-mirror API is network-reachable (AV:N, diverging from vendor AV:L); needs authenticated repo-admin rights (PR:L); flaw writes refs into other repos (I:H) but does not read them, so C:N.
Primary rating from Vendor (88ee5874-cf24-4952-aea0-31affedb7ff2).
CVSS VectorVendor: 88ee5874-cf24-4952-aea0-31affedb7ff2
Lifecycle Timeline
3DescriptionCVE.org
The Gitea push mirror API checked whether the repository owner, instead of the requesting user, may use local file system paths. On instances with [security] IMPORT_LOCAL_PATHS = true, a repository administrator who is not allowed to import local paths could add a push mirror to a local path on the server when the repository owner has that permission. Gitea then pushed the repository's refs into an existing Git repository at that path with the permissions of the Gitea process.
Technical POC Analysis
CWE-863 (Incorrect Authorization): Gitea's push-mirror creation endpoint authorizes the local-filesystem (file://) policy against the repository owner rather than the authenticated caller.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
Gitea environments that enable optional local-path imports and delegate repository administration are exposed to an access-control weakness that can undermine repository integrity. An attacker with repository-administrator rights could alter Git content on the server under the service account's authority, potentially corrupting trusted code or configuration. Leadership should care because exploitation requires non-default settings and elevated privileges, but with no vendor patch currently available, affected organizations need to reduce exposure through configuration and permission controls.
Disable [security] IMPORT_LOCAL_PATHS, remove AllowImportLocal permission from repository owners, revoke unnecessary repository-administrator rights, ensure the Gitea process cannot write to unintended local Git repositories, and monitor or alert on push-mirror and local-path import activity.
Threat Intelligence Overview
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
Authenticated command injection in Dokploy (self-hostable PaaS) versions 0.29.3 through 0.29.12 lets a low-privileged us
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
EUVD-2026-94051
NVD
CVE.org
EPSS
Vulnrichment
GitHub
VulDB
Exploit-DB