Gitea vulnerabilities
We track 58 vulnerabilities in Gitea products across 4 products. 58 are rated high or critical, and 1 has been exploited in real attacks. The most recent was published on November 1, 2026.
Latest Gitea vulnerabilities
- 9.8 Critical severity
Gitea: Improper Authentication
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
- 7.5 High severity
Gitea: Missing Authorization
Repository and organization project boards listed the pull requests that reference each issue on the board without checking whether the viewer can read them. When a private pull request mentions an issue on a board the viewer can open, the board revealed the p
- 7.5 High severity
Gitea: Incorrect Authorization
`DELETE /api/v1/orgs/{org}/repos` deletes all repositories of an organization, but it did not enforce the public-only restriction of access tokens: the route only checked that the organization itself was public. A public-only token of an owner of a public orga
- 7.5 High severity
Gitea: Improper Access Control
Gitea 1.27.3 stopped personal access tokens restricted to public resources (`public-only`) from creating repositories through `POST /api/v1/user/repos` and `POST /api/v1/repos/migrate`, but `POST /api/v1/org/{org}/repos`, `POST /api/v1/orgs/{org}/repos`, `POST
- 9.1 Critical severity
Gitea: Incorrect Authorization
The OCI registry's cross-repository blob mount checked the target package against the token's `public-only` restriction, but checked the source blob only against the full account permissions of the token owner. A `public-only` token with `write:package` scope,
- 9.1 Critical severity
Gitea: Incorrect Authorization
Gitea did not reject personal access tokens restricted to public resources (`public-only`) on the organization Actions runner registration-token endpoint, and the runner registered with the resulting token was not limited to public repositories. Holding only s
- 7.5 High severity
Gitea: Improper Authentication
Gitea resolved the principals of an SSH certificate by searching the content of all stored public keys instead of only principal keys. When Gitea trusts a user certificate authority (`SSH_TRUSTED_USER_CA_KEYS`) and accepts arbitrary principals (`SSH_AUTHORIZED
- 8.1 High severity
Gitea: Cross-Site Request Forgery
`POST /{owner}/{repo}/topics` was registered without the sign-in middleware that provides the cross-origin protection, so a request issued by a third-party site was not rejected. A repository administrator who visited a malicious page could have the topics of
- 8.1 High severity
Gitea: Incorrect Privilege Assignment
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 inform
- 8.8 High severity
Gitea Runner: Improper Privilege Management
Gitea Runner passes workflow-controlled container options into Docker job container configuration while privileged mode is disabled. Host namespace settings, expanded capabilities, and security profile overrides can remain effective despite Privileged being fo
- 8.8 High severity
Gitea: Improper Control of Generation of Code
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 an
- 7.5 High severity
Gitea: Improper Neutralization of Argument Delimiters in a Command
Gitea substitutes a URL derived from the markup Context field into external renderer command templates without escaping the reference path before shell-style argument splitting. A crafted Context can inject additional renderer arguments, including options that
- 8.8 High severity
Gitea: Missing Critical Step in Authentication
Gitea's OpenID connect handler accepts a user's password without enforcing enrolled TOTP or WebAuthn verification before completing sign-in and linking an OpenID identifier. When OpenID sign-in is enabled, an attacker who knows the victim's password can obtain
- 8.8 High severity
Gitea: Incorrect Authorization
Gitea's pull request review notifier does not attach the pull request to the Actions notification, so the fork workflow approval gate does not recognize the run as originating from a fork. Review comment and review approval or rejection events can consequently
- 8.1 High severity
Gitea: Improper Access Control
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
- 9.8 Critical severity
Gitea: Improper Limitation of a Pathname to a Restricted Directory
Gitea's Org-mode markup renderer processes INCLUDE directives supplied to the repository markup endpoint without preventing access to server-side files. An unauthenticated attacker can use a suitable public repository to read files accessible to the Gitea serv
- 7.1 High severity
Gitea: Incorrect Authorization
The Gitea push mirror API checked whether the repository owner, instead of the requesting user, may use local file system paths. On instances with `[security] IMPORT_LOCAL_PATHS = true`, a repository administrator who is not allowed to import local paths could
- 8.1 High severity
Gitea: Incorrect Permission Assignment for Critical Resource
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. A collaborator with Code write access and wi
- 9.1 Critical severity
Gitea: Improper Authentication
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 ne
- 7.5 High severity
Gitea: Uncontrolled Resource Consumption
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. A user who can open a pull request from a fork could submit a small workflow file
- 8.1 High severity
Gitea: Improper Authentication
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 existing account issued an authenticated sess
- 7.5 High severity
Gitea: Out-of-bounds Read
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 process. A user who can edit a repository
- 9.1 Critical severity
Gitea: Use of Incorrectly-Resolved Name or Reference
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 contribut
- 9.8 Critical severity
Gitea: Unintended Proxy or Intermediary
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 w
- 8.1 High severity
Gitea: Time-of-check Time-of-use (TOCTOU) Race Condition
Gitea validated a push mirror's remote address against the `[migrations]` allow and block lists only when the mirror was created. Each synchronization passed the stored address directly to `git push`, so a name that later resolved to a blocked or internal addr
- 7.1 High severity
Gitea: Incorrect Authorization
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. A holder of a writable deploy key could create protected tags with
- 9.8 Critical severity
Gitea: Improper Authentication
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 pas
- 7.5 High severity
Gitea: Server-Side Request Forgery
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. An attacker who can start a migration and control the destination's DNS c
- 7.5 High severity
Gitea: Server-Side Request Forgery
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. A repository administrator using a poli
- 8.8 High severity
Gitea: Improper Authorization
Gitea Actions blocks the jobs of workflow runs from first-time fork pull request contributors until a maintainer approves the run. The rerun path only required a run to be finished and built the new attempt's jobs without considering the pending approval, so w
- 8.8 High severity
Gitea: Improper Enforcement of Behavioral Workflow
A user who can open a fork pull request can place workflow content with a shared run-level concurrency group into a Gitea Actions run that is awaiting approval. When a later run in that group cancels the blocked job, the run becomes terminal while still marked
- 7.5 High severity
Gitea: Improper Locking
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. Because fork pull request runs are inserted under the base repository, a user who can open
- 8.1 High severity
Gitea: Least Privilege Violation
Changing an organization team's permission through the API with only the `permission` field did not rebuild the team's per-unit access, and the requested level was not applied as a cap. After an organization owner demoted a team, for example from admin to read
- 9.1 Critical severity
Gitea: Authentication Bypass by Primary Weakness
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
- 7.7 High severity
Gitea: Origin Validation Error
When `[migrations] ALLOWED_DOMAINS` was configured, a hostname matching the allow list was accepted without checking its resolved address against the local-network restrictions. A user who can start repository migrations and control the DNS of an allowed hostn
- 9.8 Critical severity
Gitea Code Injection Exploited
Gitea before 1.27.1 allows remote code execution via the diffpatch API through Git hook installation.
- 7.6 High severity
Gitea: Server-Side Request Forgery
Gitea prior to 1.27.0 contains a server-side request forgery vulnerability that allows authenticated attackers to bypass SSRF protections by exploiting HTTP fetch operations in migration and OAuth avatar code paths that use Go's default http.Get without a cust
- 7.1 High severity
Gitea Open Source Git Server: Authorization Bypass Through User-Controlled Key
Gitea versions up to and including 1.26.2 allow Git LFS object reuse to authorize private source objects for users who have repository access but lack Code-unit access.
- 8.7 High severity
Gitea Open Source Git Server: Improper Neutralization of Input During Web Page Generation
Gitea versions from 1.25.0 before 1.26.0 allow stored cross-site scripting through the extensionsRequired field in glTF files rendered by the 3D file viewer.
- 9.8 Critical severity
Gitea Open Source Git Server: Incorrect Authorization
Gitea versions before 1.26.0 do not fail closed on bufio.Scanner errors while processing pre-receive hook input, allowing oversized input to bypass branch-protection checks.