Priority LOW 27
The Gitea API endpoint `GET /api/v1/repos/{owner}/{repo}/media/{filepath}` wrote files of up to 1 KiB that are stored directly in Git, not in LFS, to the response without the content type and disposition headers Gitea us…
Vulnerabilities
81 records
Priority MEDIUM 58
With `[repository] FORCE_PRIVATE = true`, Gitea creates new repositories as private, but the post-receive hook still applied the `repo.private=false` push option to an empty repository created by push.
Priority LOW 19
The Gitea API routes for issue attachments (`/api/v1/repos/{owner}/{repo}/issues/{index}/assets/{attachment_id}`) also accepted attachments that belong to comments on the issue.
Priority LOW 35
The Gitea web route for deleting tags (`POST /{owner}/{repo}/tags/delete`) requires only write access to the Code unit, but shares its handler with release deletion and did not check that the target was a plain tag.
Priority LOW 29
When migrating a repository from another Gitea instance, Gitea used the page size reported in the source server's API settings to end its paginated downloads.
Priority MEDIUM 47
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.
Priority LOW 22
The Gitea API endpoint for creating push mirrors (`POST /api/v1/repos/{owner}/{repo}/push_mirrors`) checked only whether mirroring was enabled and not the `[mirror] DISABLE_NEW_PUSH` setting that the web interface enforc…
Priority LOW 32
The Gitea push mirror API checked whether the repository owner, instead of the requesting user, may use local file system paths.
TI-2026-68505 CVE-2026-73278
WebAuthn bypass in Gitea OAuth and OIDC sign-in
Priority MEDIUM 49
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.
Priority LOW 20
When a private repository is transferred to a user who lacks access, Gitea grants that recipient temporary read access as a collaborator so they can review the repository.
Priority LOW 39
Gitea expanded a workflow's static `strategy.matrix` into its full Cartesian product without a size limit when creating a run, before the fork pull request approval gate applied.
Priority LOW 38
When Gitea's web installer is reachable against a database that already contains users, such as after `INSTALL_LOCK` has been reset to `false`, submitting the install form with an administrator username matching an exist…
Priority LOW 19
With `[migrations] ALLOWED_DOMAINS` set to a matching entry such as `*` or a hostname wildcard, Gitea's migration URL validation could permit reserved and link-local addresses, such as `169.254.169.254`, even when `ALLOW…
Priority LOW 39
A repository's external issue tracker regular expression containing alternating capture groups could produce invalid slice indexes when Gitea rendered issue references, causing a runtime panic that terminated the Gitea p…
Priority LOW 29
When processing issue and comment bodies, Gitea scanned the entire preceding text for action keywords such as "closes" or "fixes" once per Markdown link, giving processing time quadratic in the input size.
Priority MEDIUM 50
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.
Priority LOW 31
When a push was authenticated with a deploy key, Gitea recorded the repository owner as the pusher, so permission checks in the push hook pipeline evaluated the owner instead of the deploy key.
Priority LOW 39
Gitea validates a repository migration hostname against its network allow and block lists before invoking Git, but the Git subprocess independently resolves the hostname when connecting.
Priority LOW 38
Gitea validated the initial remote URL for push mirrors, wiki remote checks, and fetches of migrated pull request heads, but the subsequent raw Git operations followed HTTP redirects without revalidating the destination.
Priority MEDIUM 47
Gitea accepted pushed Git trees containing two entries with the same name, which Git's own consistency checks reject.
Priority LOW 37
Gitea validated a push mirror's remote address against the `[migrations]` allow and block lists only when the mirror was created.
Priority LOW 38
When a Gitea Actions run was inserted, older runs in the same workflow-level concurrency group were cancelled without checking whether the new run still needed approval.
Priority LOW 24
Gitea's container registry served blob downloads with a `Content-Type` taken from the media type declared in pushed image manifests, without a `Content-Disposition` or restrictive content security policy.
Priority LOW 19
Gitea's repository migration and pull mirror egress checks could be bypassed with a hostname that returns multiple DNS answers, because the address that was validated was not necessarily the address Git later connected t…
Priority LOW 33
When `[migrations] ALLOWED_DOMAINS` was configured, a hostname matching the allow list was accepted without checking its resolved address against the local-network restrictions.