Gitea EUVD-2026-94065

Requires the non-default setting [repository] FORCE_PRIVATE = true to be enabled on the Gitea instance; the default configuration is explicitly not affected. The attacker must be an authenticated user who holds repository-creation permission (CVSS PR:L), and must create a new, empty repository via git push while supplying the repo.private=false push option - the flaw lives in the post-receive hook's handling of that option on push-created empty repositories. Limiting factors: the vulnerable code path only triggers for a repository created by the push itself (not pre-existing repos), the operator must have opted into FORCE_PRIVATE, and admin-created repos/admin doers are unaffected by the fixed logic. Only instances on versions 1.27.0-28.0.0 are affected; v28.1.0 adds the (isPrivate.Value() || !setting.Repository.ForcePrivate || ctx.Doer.IsAdmin) guard.

This is a genuine but modest-priority issue, not a high-urgency flaw. The CVSS 3.1 base score is 5.4 (Medium) with vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, meaning network-reachable over git push, low complexity, but requiring an authenticated user who already holds repository-creation rights (PR:L). CWE-863 (improper authorization) accurately describes the defect: an instance-wide confidentiality policy (FORCE_PRIVATE) is bypassed. No EPSS score, KEV listing, SSVC decision, or POC was provided in the input - exploitation-probability and automation signals are therefore absent, not low; treat the real-world exploitation likelihood as undetermined rather than confirmed-low. The single most important mitigating signal is in the description itself: 'The default configuration is not affected.' Exploitation requires the non-default [repository] FORCE_PRIVATE = true setting, so the exposed population is limited to the subset of instances deliberately enforcing mandatory-private repositories - precisely the environments where the bypass matters most. The impact is also bounded: a user makes their OWN newly pushed repository public, so this is a policy/governance bypass and metadata-exposure issue rather than theft of other users' private data. Net: a legitimate authorization-control defect worth patching on FORCE_PRIVATE instances, but it is correctly rated Medium and does not warrant emergency response; the input tag 'Authentication Bypass' overstates it - this is authorization, not authentication, bypass.

On a Gitea instance hardened with [repository] FORCE_PRIVATE = true, a low-privileged but repo-creating user pushes to a brand-new repository and supplies the repo.private=false push option. The post-receive hook honors that option on the freshly created empty repository, publishing it publicly in violation of the instance's mandatory-private policy. No public exploit code was identified at time of analysis; the vendor fix in PR #39501 confirms the mechanism.