CVE-2026-120263
Low risk· EPSS 10%Exploitation Probability (EPSS)
Low risk10th percentile - higher than 10% of all known CVEs
Summary
In Gitea, when [oauth2_client].ACCOUNT_LINKING is set to auto (not the default) and registration is enabled, the link-account sign-up form looked up the existing account by the submitted user name or email instead of the identity asserted by the OAuth2 provider. An attacker with an account on a configured OAuth2 provider could submit another user's name, link their external identity to that Gitea account and sign in as it without a password, including as an administrator; the link persisted for later sign-ins.
Risk Assessment
The vulnerability allows account takeover of another user, including an administrator, without knowing the password. This leads to full compromise of the Gitea instance.
Recommendation
Update Gitea to a version with the fix, where automatic linking only occurs when the provider's email or provider-derived user name matches. Until then, disable the auto setting for ACCOUNT_LINKING.
Other vulnerabilities in Gitea
See all- CVE-2026-73273Medium
Gitea's Maven upload handler reads checksum uploads entirely into memory and returns before enforcing package-size quotas. An authenticated user with package-publish permission can submit an oversized body to a checksum endpoint, bypassing the upload quota and exhausting server memory.
- CVE-2026-73135Medium
Gitea uses inconsistent repository visibility predicates, and the condition used by some repository-listing endpoints admits repositories whose owners are hidden from the viewer. Those listings disclose repository metadata even though direct routes correctly deny access with a 404 response.
- CVE-2026-73130Medium
Gitea does not limit the length of the gitignores field accepted by repository-creation forms and the API. Repository initialization splits the field into template names, repeatedly reads the referenced templates, and buffers their contents in memory. An attacker who can create repositories can submit an oversized value to amplify template reads and memory use, impairing availability.
- CVE-2026-73126Medium
Gitea's Actions workflow status badge endpoint does not enforce repository-read scope or the public-only restriction on the token authenticating the request. A token lacking read:repository, or restricted to public repositories, can retrieve the latest workflow status of a private repository accessible to its owner. This discloses private workflow status beyond the token's intended delegated permissions.
- CVE-2026-71301Medium
Gitea's repository markup endpoint resolves same-repository pull request references without enforcing the viewer's Pull Requests permission. A member with only Wiki access to a private repository can submit a markup preview request and retrieve a private pull request's title and state icon despite lacking Issues and Pull Requests access. This exposes pull request metadata across repository unit permissions.
- CVE-2026-70407Medium
Gitea's organization-list API does not enforce the read:organization token scope. A token limited to another category, such as read:misc, can retrieve organization metadata visible to its owner. For a site administrator's token, the response can include Limited and private organizations, bypassing the intended restriction on the token's delegated access.
- CVE-2026-70406Medium
Gitea's shared comparison helper omits the token repository-access check used when updating pull requests. A public-only token with read:repository scope can route a comparison or pull request creation through a public base repository and retrieve commit history and diffs from a private head repository accessible to the token owner. This bypasses the token's public-only restriction; it does not remove the account's underlying repository permission checks.
- CVE-2026-70402Medium
Gitea creates server-side Git hook directories and scripts with mode 0777 and relies on the process umask to restrict access. With a permissive umask such as 0000 or 0002, another local user who can reach the repository storage may modify a hook or add an executable to a writable hook directory. A later Git operation can execute that file as the Gitea service account.
- CVE-2026-70400Medium
Gitea's repository migration API accepts a public-only token when the request specifies creation of a private repository. A delegated token intended to operate only on public resources can create a private repository and migration task under the authorizing account or an organization where that user has the necessary permissions. The ordinary private repository-creation route rejects the same token, but the migration path omits that restriction.
- CVE-2026-68964Medium
Gitea's user SSH and GPG key-list API endpoints omit the profile visibility check applied by their web equivalents. A restricted account can retrieve public keys, key titles, fingerprints, and GPG-embedded email addresses belonging to Limited-visibility users. The disclosure concerns public key material and associated metadata, not private cryptographic keys.
Original NVD description (English source)
When `[oauth2_client].ACCOUNT_LINKING` is set to `auto` (not the default) and registration is enabled, the link-account sign-up form looked up the existing account to link by the user name or email submitted in the form instead of the identity asserted by the OAuth2 provider. An attacker with an account on a configured OAuth2 provider could submit another user's name, link their external identity to that Gitea account and be signed in as it without its password, including as an administrator. The link persisted for later sign-ins. Automatic linking now only happens when the existing account matches the provider's email or provider-derived user name; otherwise the account password is required.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS