Gitea EUVD-2026-94051

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.

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.

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).