Gitea vulnerabilities

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.

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 a pull request from a fork could cancel trusted in-progress runs that share a concurrency group with `cancel-in-progress` enabled, without approval and without running any code. On self-hosted runners this can interrupt deployments and leave partial state behind.

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 blob containing HTML and JavaScript with a `text/html` media type. When a victim who is authenticated to the instance opens the blob URL in a browser, the script runs on the Gitea origin and can perform actions as the victim, such as creating API tokens.

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, the team's members kept their previous unit permissions, including write access to the team's repositories. The web form was not affected.

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 migrations or mirrors could direct the server to internal services, reading from and writing to reachable internal Git or HTTP endpoints. Content from internal responses could additionally be disclosed through migration and mirror error messages.

In Gitea, when `[migrations] ALLOWED_DOMAINS` was configured, a hostname matching the allow list was accepted without checking its resolved address against local-network restrictions. A user who can start repository migrations and control the DNS of an allowed hostname could make it resolve to loopback or private addresses and bypass `ALLOW_LOCALNETWORKS = false`, reaching internal services from the Gitea server. Instances without `ALLOWED_DOMAINS` configured are not affected by this specific bypass.

Unbounded Arch package file metadata can cause resource amplification in Gitea package uploads.

Webhook Authorization Header Returned in Plaintext via API.

GHSA-8fwc-qjw5-rvgp ClearRepoWatches fix not applied to API EditRepo path — sister code path retains stale watches on public->private.

Private Repository Existence Disclosure via go-get Meta Endpoint.

Cross-repository label-ID enumeration oracle via unscoped DeleteIssueLabel API.

Personal access token scope enforcement bypass on the repository home page (`GET /{owner}/{repo}`) discloses private repository contents.

Repository migration SSRF via multi-answer DNS allow-list bypass.

SSRF in restore-repo via unsanitized pull_request.yml Head.CloneURL.

Webhooks created by a collaborator keep firing after their repo access is revoked, enabling ongoing real-time exfiltration of private repo content. The issue stems from incomplete revocation cleanup in `DeleteCollaboration`.

Branch protection can be bypassed via PR retargeting, preserving a stale `official` approval flag. This allows changes to be pushed to protected branches without the required approval.

A cross-repository IDOR in issue-dependency removal lets an attacker tamper with and comment on private repos they cannot access. There is a lack of proper object-level authorization.

The vulnerability allows manipulation of repository visibility via Git push options. An attacker can change repository visibility (e.g., from private to public) without proper permissions.

ParseAcceptLanguage in the Locale middleware causes a quadratic-time DoS on unauthenticated requests. Sending specially crafted Accept-Language headers can overload the server.

A vulnerability in Gitea LFS allows privilege escalation via deploy keys. A person with a deploy key can gain higher privileges than intended.

Private repository metadata remains accessible after access revocation. This means that information about the repository (e.g., name, description) may still be visible to users who lost permissions.

In code.gitea.io/gitea, there is missing authorization and authorization bypass through user-controlled key, incorrect permission assignment for critical resources, and exposure of sensitive information to an unauthorized actor.

The public-only API token restriction is not enforced on team API routes. This means a token intended for public access only can access team data that should be private.

The vulnerability allows bypassing the public-only scope of personal access tokens in organization and permission endpoints. This means a token intended only for public operations can access operations requiring broader privileges.

The vulnerability allows bypassing the release attachment extension allowlist via the web release edit form. This is a variant of CVE-2025-68939.

The vulnerability leaks the member list of private organizations via the /members API endpoint. This is an incomplete fix for PR #38145.

The vulnerability in OAuth token introspection returns metadata of tokens issued to other clients, violating section 4 of RFC 7662.

The vulnerability allows Local File Inclusion via file:// URI in the Migration Restore function. An attacker can read arbitrary files from the server's filesystem.

The vulnerability in the REST API exposes organization membership of private organizations to the public. Unauthorized individuals can obtain information about members of private organizations.

The vulnerability in Fork-PR Actions tasks allows reading a third private repository via the collaborative-owner branch. A missing fork-PR guard enables this.

Two Server-Side Request Forgery (SSRF) findings in Gitea 1.26.2. They allow an attacker to make requests from the server to internal resources.

The vulnerability enables cross-repository information disclosure via Org-Level Actions Run/Job APIs. An attacker can obtain data from other repositories.

The vulnerability in repository migration follows Git HTTP redirects after URL allow/block validation, enabling internal Git repository exfiltration.

The vulnerability allows re-linking attachments to issues/comments across repositories, potentially exposing private attachment content.

The vulnerability causes denial of service (CPU and memory exhaustion) via O(N^2) string concatenation during Debian package upload.

The SSH key parser in Gitea is vulnerable to denial of service, potentially leading to system overload.

OAuth2 sign-in can reactivate an administrator-deactivated account on auth sources without refresh tokens (incomplete fix of #38009).

The Email Management API bypasses ManageCredentials feature restrictions, allowing unauthorized operations on email addresses.

Null pointer dereference in the AddTime API causes authenticated denial of service.