Gitea vulnerabilities

In Gitea, the 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 load workflow code from the fork head and run it on the base repository's runners without the required maintainer approval.

In Gitea, first-time fork contributor approval is enforced 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.

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.

A vulnerability in Gitea up to version 1.26.1 is caused by insufficient permission checks for Composer package source links. This can expose private or internal package source information.

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.

Requesting a user or organization profile page with an Accept header for RSS/Atom returned the owner's activity feed without the visibility check applied by the profile page and .rss/.atom routes. Anonymous, restricted users and non-members could confirm the existence of limited or private users/organizations and read their profile details and public activity, even when ENABLE_FEED was disabled. Activity in private repositories was not included.

The Gitea API endpoint for creating push mirrors checked only whether mirroring was enabled, not the [mirror] DISABLE_NEW_PUSH setting enforced by the web interface. A repository administrator could create new push mirrors on instances where the site administrator had disabled them. A push mirror pushes all refs of the repository to a remote chosen by the caller, on each commit or on a schedule.

The Gitea API endpoint GET /api/v1/repos/{owner}/{repo}/media/{filepath} wrote files up to 1 KiB stored directly in Git (not LFS) to the response without the content type and disposition headers Gitea uses for user content. An HTML file committed to a repository was rendered by the browser on the Gitea origin. A user with push access could run JavaScript in the session of a victim opening the media URL and act with the victim's permissions.

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 repository public in violation of the instance policy. The default configuration is not affected.

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 without local path import permission could add a push mirror to a local path on the server when the repository owner has that permission. Gitea then pushed the repository's refs into an existing Git repository at that path with the permissions of the Gitea process.

The Gitea API routes for issue attachments 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 user who opened an issue could rename or delete attachments that other users had posted in comments on that issue. The contents of the attachments could not be changed.

The Gitea web route for deleting tags 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 without Releases write access could permanently delete published releases of that repository, including their attachments. Protected tag rules covering the release tag still blocked the deletion.

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 memory until it was exhausted. Any user who can migrate repositories could point a migration at a server they control and cause a denial of service.

When a private repository is transferred to a user without access, Gitea grants temporary read access as a collaborator. Rejecting or cancelling the transfer did not revoke this collaboration, so the recipient kept persistent read access to the private repository, including code, issues, pull requests, and wiki, and could clone it. The repository owner was not notified. Transfer-granted access is now removed while pre-existing collaborations are preserved.

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 whose matrix expands to a very large number of jobs, consuming server memory and potentially terminating the Gitea process. No runner is required. Static matrices above 256 combinations are now rejected before expansion.

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 session for that account without verifying its password. If the account is an administrator, the session grants full administrative access, including changing the account's password. Databases with a single user also did not require the reinstall confirmation.

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-network block list did not cover these ranges, and a hostname matching the allow list was accepted regardless of its resolved address. A user who can start migrations on such an instance could reach these addresses from the Gitea server; the default empty `ALLOWED_DOMAINS` configuration is not affected.

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's external issue tracker settings could make any later rendering of matching content, such as viewing a README, crash the instance for all users.

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 content could send a crafted body of about 1 MB that keeps a CPU core busy for several minutes while holding a database transaction open.

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 address was still reached. A user with administrator access to a repository, which includes repositories they create themselves, could aim push mirror synchronization at internal Git services and force-push the repository's contents to them.

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 without being on the tag allow list and change repository visibility through push options, for example making a private repository public. Pull requests created through the AGit flow with a deploy key were also attributed to the owner.

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 can change the address between validation and connection to reach a blocked internal address. The affected path is the Git clone operation; validation in the migration HTTP client's dialer does not protect the independently connecting Git subprocess.

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 policy-allowed endpoint that redirects could make Gitea's Git client send requests to an address that the outbound host policy would otherwise block. The impact depends on the configured policy and the internal services reachable from the server.

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 when a user with Actions write access cancelled a run that was awaiting approval and then re-ran it, the new jobs were created as waiting rather than blocked while the run still recorded that approval was required. Cancelling and re-running stale fork checks is a routine action that does not involve the approval control, so where Actions is enabled and a matching runner is registered, workflow code taken from the fork pull request head could run on the repository's runners without an explicit 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 marked as needing approval. If a maintainer later approves the run, Gitea passed the already-cancelled job back through concurrency preparation, set it to waiting, and made it claimable by a matching runner, executing fork-controlled workflow code. Exploitation requires the maintainer's later approval action, Actions to be enabled, and a runner that accepts the repository's jobs.