Gitea vulnerabilities

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Gitea's API and web issue-search paths do not treat restricted accounts as anonymous viewers when evaluating Limited-visibility repository owners. A restricted user can search and retrieve issue titles and bodies that should be hidden by the owner's visibility policy. Keyword matching can also reveal that hidden issue content or comments contain a supplied term.

Gitea's activity-feed and contribution-heatmap API handlers do not apply the profile visibility check for restricted accounts viewing Limited-visibility users. A restricted user can retrieve activity records and contribution timestamps that the corresponding profile routes deny. Exposed activity can include repository names, commit messages, and issue or pull request events associated with qualifying public-repository activity.

In Gitea, for pull request events the workflow definition is read from the pull request head, and a synthetic skipped status is posted when branch or path filters exclude execution. A fork pull request author can supply a workflow matching a required status context while deliberately preventing it from running, and skipped statuses count as success.

Gitea's user organization-list API returns Limited-visibility organizations to authenticated restricted accounts without applying the visibility restriction enforced by the single-organization endpoint. A restricted user can list a known user's public organization memberships and retrieve limited organizations' names, descriptions, and avatars.

Gitea's package registry grants authenticated users read access to packages owned by Limited-visibility users without excluding restricted accounts. A restricted user can enumerate and download those packages despite the visibility policy that should prevent this access.

Gitea's collaborative-owner authorization path for reading cross-repository reusable workflows does not exclude fork pull request runs. An approved fork workflow targeting a private repository can read workflow files from another private repository that trusts the base repository's owner through collaborative-owner configuration.

Gitea's Swift package parser limits each manifest to 128 KiB but does not limit the number of manifests or their aggregate size before reading them into memory. An authenticated user with package-publish permission can upload a highly compressed archive containing many manifests, causing allocations far larger than the uploaded archive.

Gitea parses Alpine package uploads before enforcing package-size quotas and does not bound the decompressed .PKGINFO data or its dependency and provides entry counts. An authenticated user with package-publish permission can upload a small, highly compressed archive that causes disproportionately large memory allocations during parsing and metadata generation.

Gitea's OneDev migration downloader reads the entire remote version response into memory without a size limit and uses a client without a timeout. An authenticated user who can start a repository migration can direct it to an attacker-controlled OneDev-compatible server returning an oversized or never-ending response.

Gitea's Jupyter notebook renderer inserts the notebook's language_info.name metadata into a CSS class attribute while disabling sanitization and rendering directly in the main document without an iframe sandbox. A malicious repository notebook can supply multiple CSS classes that create a viewport-covering overlay and intercept clicks when another user views it. The reported impact is UI redress; script execution was not demonstrated.

Gitea's starred-repository and tracked-time API endpoints do not re-check current repository permissions before returning data associated with the requesting user. A user whose access to a private repository has been revoked can still retrieve repository metadata through /api/v1/user/starred and private issue titles through /api/v1/user/times.

When OpenID sign-in is enabled, Gitea accepts a user-supplied OpenID URL and performs discovery requests without validating the destination against internal network addresses. An unauthenticated remote attacker can cause the server to contact loopback or private-network HTTP services.

Gitea's Org-mode markup renderer processes INCLUDE directives without preventing access to server-side files, allowing an unauthenticated attacker to read files accessible to the Gitea service account and potentially execute commands via Git hook modification.

Gitea's OAuth2 token endpoint verified the signature and grant of a token submitted with the refresh_token grant type, but not that the token was a refresh token. An unexpired access token for the same OAuth2 application and grant could be exchanged for a new access token and refresh token. Whoever holds such an access token could keep access beyond the token's original lifetime.

Gitea accepted pushed Git trees containing two entries with the same name, which Git's own consistency checks reject. Gitea's web views resolved such a path to the first entry, while `git checkout`, Gitea Actions, and release archives use the last. A contributor could open a pull request whose diff and file views show benign content while CI and checkouts at the same commit use different, attacker-controlled content. Incoming objects are now checked for consistency; objects already stored in existing repositories are not rescanned.

Gitea Actions decided whether a fork pull request run needed approval based on the user who triggered the event rather than the pull request author. For `pull_request` activity triggered by a maintainer during ordinary triage, such as adding a label, the run was created without requiring approval, while the workflow definition was still taken from the fork head. Where Actions is enabled and a matching runner is registered, fork-controlled workflow code could run on the base repository's runners without an explicit approval.

Gitea's OAuth2 and OpenID Connect sign-in paths do not require a WebAuthn challenge when WebAuthn is the account's only configured second factor. A party able to authenticate through the affected external identity flow can obtain a full session without the passkey verification enforced during password login. One affected path can also persist an external identity link, extending the compromise beyond the initial session; accounts with TOTP configured are outside the reported WebAuthn-only scenario.

When Gitea's built-in SSH server is enabled (`START_SSH_SERVER = true`), the presented public key was looked up with an SQL `LIKE` comparison of its encoded content, which is case-insensitive on some databases, including the default SQLite. An attacker who can construct a case variant of another user's registered RSA public key for which they can derive the private key could have that key matched to the victim's account and authenticate over SSH as that user. Keys are now looked up by fingerprint.

Two SSRF vulnerabilities in Gitea migration/mirror (DNS rebinding + missing re-validation).

Public-only repository tokens can update private PR head branches.

The team-repository linking endpoint bypasses the RepoAdminChangeTeamAccess organization setting. This means a user without proper permissions can change repository-team assignments.

Theft of the Remember-Me token in Gitea does not invalidate the attacker's session, allowing continued unauthorized access.

The vulnerability allows privilege escalation via access token scope escalation in the API.

A public-only scope token can bypass restrictions on limited-visibility owners (Repository and Package categories) — residual after CVE-2026-25714 / PR #37118.

The OIDC userinfo endpoint returns identity claims without enforcing API token scopes.

The vulnerability in Gitea Actions Artifacts V4 stems from HMAC ambiguity in signed URLs, allowing cross-repository artifact read and cross-task upload-state write.

A vulnerability in Gitea before version 1.26.0 fails to close the connection on bufio.Scanner errors while processing pre-receive hook input, allowing oversized input to bypass branch-protection checks.

The vulnerability in Gitea before version 1.25.5 is that LFS push and sync mirror operations do not use the migration HTTP transport, bypassing the configured migration transport protections for those LFS requests.

A vulnerability in Gitea before version 1.25.5 does not correctly persist the OAuth2 PKCE S256 challenge method during authorization, allowing token exchange without the required verifier check.

A vulnerability in Gitea versions before 1.25.5 allows reusing expired or single-use OAuth2 authorization codes during token exchange. Inconsistent enforcement of code expiry and single-use behavior may lead to unauthorized access.

A vulnerability in Gitea before version 1.25.5 mishandles path resolution during template repository generation, allowing template processing to read or write through symlinked or otherwise non-regular paths.

CVE-2026-22874 affects Gitea versions up to and including 1.26.2. The SSRF (Server-Side Request Forgery) protection in webhook and migration allow-list filtering is incomplete, potentially allowing an attacker to make unauthorized requests to internal network resources.

In Gitea before version 1.25.5, validation constraints for repository creation fields are missing, including length-limited template fields and trust model or object format values.

Gitea Docker images up to version 1.26.2 set REVERSE_PROXY_TRUSTED_PROXIES=* by default, allowing any source IP to impersonate a user when reverse-proxy authentication headers like X-WEBAUTH-USER are enabled.

A vulnerability in Gitea up to version 1.26.1 allows repository archive downloads to bypass token scope checks on the web archive download endpoint.

A vulnerability in Gitea allows improper validation of repository ownership when linking attachments to releases. An attachment uploaded to a private repository could be linked to a release in a different public repository, making it accessible to unauthorized users.

Gitea does not properly validate repository ownership when deleting Git LFS locks. A user with write access to one repository may be able to delete LFS locks belonging to other repositories.

Gitea does not properly validate project ownership in organization project operations. A user with project write access in one organization may be able to modify projects belonging to a different organization.

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.