Summary
Ein Angreifer kann mehrere Schwachstellen in Gitea ausnutzen, um beliebigen Programmcode auszuführen, erweiterte Berechtigungen zu erlangen, Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren oder offenzulegen sowie Cross-Site-Scripting-Angriffe durchzuführen.
Product
Gitea ist ein quelloffener Github-Klon.
Vulnerabilities 29
-
Critical 9.8
Gitea fork workflow approval bypass through maintainer-triggered events
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 …
-
Critical 9.1
Gitea OAuth2 refresh token grant accepts access tokens
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 n…
-
Critical 9.1
Gitea built-in SSH server authentication bypass through key case folding
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 ca…
-
Critical 9.1
Gitea review and execution mismatch through duplicate tree entries
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 contribu…
-
High 8.8
Gitea fork workflow job revival through later approval
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 marke…
-
High 8.8
Gitea fork workflow approval bypass through cancel and rerun
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 …
-
High 8.1
Gitea API team demotion not applied to unit permissions
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 rea…
-
High 8.1
Gitea tag delete route deletes releases without release permission
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 w…
-
High 8.1
Gitea push mirror SSRF and forced writes to internal Git hosts
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 add…
-
High 8.1
Gitea installer authentication bypass for existing accounts
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 ses…
-
High 7.7
Gitea migration SSRF through ALLOWED_DOMAINS address check bypass
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 host…
-
High 7.5
Gitea trusted workflow cancellation by unapproved fork runs
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 ope…
-
High 7.5
Gitea SSRF through Git HTTP redirects in mirrors and fetches
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 pol…
-
High 7.5
Gitea repository migration SSRF through DNS rebinding
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 …
-
High 7.5
Gitea denial of service through external issue tracker patterns
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 repositor…
-
High 7.5
Gitea Actions memory exhaustion through large static matrices
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 fil…
-
High 7.1
Gitea deploy key pushes acting as the repository owner
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 wit…
-
High 7.1
Gitea push mirror local path check uses the repository owner
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 coul…
-
Medium 6.5
Gitea migration memory exhaustion from zero page size
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. A source that reported `max_response_items` as `0` made these loops run indefinitely and grow server…
-
Medium 6.5
Gitea issue reference parsing CPU exhaustion
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. An authenticated user able to submit issue or comment…
-
Medium 6.1
Gitea repository media API stored XSS
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 uses for user content. An HTML file commi…
-
Medium 5.4
Gitea container registry stored XSS through blob media type
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. A user who can push container images can publish a blo…
-
Medium 5.4
Gitea push-to-create bypass of FORCE_PRIVATE policy
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. Any user who can create repositories could make their new…
-
Medium 4.9
Gitea push mirror API bypass of DISABLE_NEW_PUSH policy
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 enforces. A repository administrator could th…
-
Medium 4.3
Gitea migration and pull mirror SSRF through multi-answer DNS
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 to. A low-privileged user who can create…
-
Medium 4.3
Gitea issue attachment API allows changing comment attachments
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. Because the author of an issue may edit and delete the issue's attachments, a use…
-
Medium 4.3
Gitea migration SSRF to reserved addresses through ALLOWED_DOMAINS
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_LOCALNETWORKS = false`. The local-netw…
-
Medium 4.3
Gitea private repository access retained after rejected transfer
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. Rejecting or cancelling the transfer did not revoke this collaboration, so the named re…
-
Medium 4.3
Gitea profile feed disclosure bypassing user visibility
Requesting a user or organization profile page (`GET /{username}`) with an `Accept: application/rss+xml` or `Accept: application/atom+xml` header returned the owner's activity feed without the visibility check that the profile page and the `.rss` and `.atom` …
Revision history
-
#1
Initiale Fassung
References
-
Gitea Release Notes vom 2026-10-06
https://blog.gitea.com/release-of-28.0.0/