| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Gitea's web attachment handler skips its cross-repository ownership check for attachments created before 16 January 2026 and checks permissions against the repository named in the request URL instead. An unauthenticated attacker who knows a private attachment's UUID can request it through a public repository's attachment path and retrieve its contents. This can expose issue and pull request attachments or release assets; the random attachment UUID must already be known to the attacker. |
| When OpenID sign-in is enabled, Gitea processes unauthenticated assertion parameters and sends an HTTP POST request to the caller-supplied OpenID provider endpoint during verification. An attacker controls the destination and much of the form body, allowing interaction with internal HTTP services reachable from the Gitea server. The response is not returned to the attacker, so the issue is blind SSRF; its impact depends on the services and network addresses the server can reach. |
| Gitea's collaboration access-mode endpoint accepts the Owner access mode from an authenticated repository collaborator with Admin access. The collaborator can promote their effective permissions from Admin to Owner and then perform owner-only operations, including transferring the repository to their own account. This bypasses the intended boundary between repository administration and ownership. |
| Gitea allows a token with write:user scope to register an attacker-controlled SSH public key on the token owner's account. API requests signed with the corresponding private key authenticate as that account through HTTP Signature without API token scope information, causing route-level token scope checks to be skipped. This converts a user-scoped token into an unscoped API authentication method while retaining the account's normal role and repository permissions. |
| Gitea resolves local reusable workflow files from a fork's head commit when a trusted base-branch workflow runs for a pull_request_target event. A fork author can modify a referenced reusable workflow so attacker-controlled code executes with the repository and organization secrets available to that event. Exploitation requires a base workflow that calls a local reusable workflow, and bypasses the intended separation between trusted base code and untrusted fork code. |
| Gitea's organization repository-creation API requires write:organization but omits the write:repository token scope enforced by other repository-creation routes. A personal access token or OAuth application token without repository-write scope can therefore create organization-owned repositories if the authorizing user has permission to do so. This bypasses the token's delegated scope boundary while remaining subject to the user's organization permissions. |
| Gitea's initial GitLab migration version probe uses an HTTP client without a timeout and does not attach the migration task's cancellation context. An authenticated user who can start migrations can target an attacker-controlled server that keeps the response open indefinitely. The request continues after task cancellation and can exhaust the migration worker pool, preventing other migrations from progressing. |
| 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'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 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 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 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. The issue affects user-owned package registries and exposes package contents across the intended authorization boundary. |
| Gitea's user organization-list API includes Limited-visibility organizations for 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. This exposes organization metadata that should be hidden from the requesting account. |
| For pull request events, Gitea reads workflow definitions from the pull request head and posts a synthetic skipped status when workflow branch or path filters exclude execution. A fork pull request author can supply a workflow matching a required status context but deliberately prevent it from running. Because skipped statuses count as success, branch protection or organization-required workflow checks can appear satisfied without the mandated workflow executing; no runner or maintainer approval is required for this path. |
| Gitea enforces first-time fork contributor approval by blocking jobs, but some job transition and dispatch paths do not re-check the run's approval requirement. A separate run sharing a job-level concurrency group can cancel a pending job and cause its blocked sibling jobs to be re-emitted and dispatched without approval. This allows unreviewed workflow code to execute on self-hosted runners; fork secrets remain withheld and the run token remains read-only. |
| 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. |
| 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 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 repository-side team-link API allows a repository administrator who is not an organization owner to attach organization teams to a repository despite RepoAdminChangeTeamAccess being disabled. The endpoint does not enforce the organization's restriction on repository administrators changing team access. This allows unauthorized changes to which organization teams receive repository access. |
| 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. The disclosure depends on relationships or tracked-time entries created before access was revoked. |
