Gitea vulnerabilities

In Gitea, the web profile and RSS/Atom feed routes of users and organizations checked only whether a signed-in viewer could see a limited-visibility owner, without considering the public-only restriction of the personal access token used to authenticate. Any user holding a public-only token could send it over HTTP Basic authentication to read the profile and activity feed of limited-visibility users and organizations, which are hidden from anonymous visitors and refused on the equivalent API routes.

In Gitea, the /{username} web route accepted personal access tokens over HTTP Basic authentication without checking their scope. A token confined to an unrelated scope, such as read:issue, could read its owner's private activity through the user RSS/Atom feed and the profile activity tab, and other members' activity in a private organization through the organization feed; a public-only token could list the owner's private repositories and organizations and render private profile READMEs. For a site administrator's token this applied to every account.

In Gitea, 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 private repository's path and the pull request's number, title and state, to anonymous visitors in the case of a public board. The pull request body, diff and files were not exposed.

In Gitea, the DELETE /api/v1/orgs/{org}/repos route deletes all repositories of an organization but did not enforce the public-only restriction of access tokens: it only checked that the organization itself was public. A public-only token of an owner of a public organization could therefore permanently delete the organization's private repositories, which such a token must not reach.

In Gitea, the web interface blocks issue and pull request changes on archived repositories, but several issue routes of the REST API did not check whether the repository is archived. A user allowed to change issues of an archived repository could use the API to edit, close or delete issues, change labels and deadlines, add or delete tracked time and stopwatches, add reactions, change issue blocks, and pin issues, altering data that archiving is meant to freeze.

In Gitea 1.27.3, personal access tokens restricted to public resources (public-only) were stopped 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 /api/v1/orgs and POST /api/v1/repos/{owner}/{repo}/generate still accepted such tokens. A holder of a public-only token with the needed write scopes could create private repositories in organizations where the token's owner may create repositories, create private organizations, and generate private repositories from templates.

In Gitea, the OAuth2 userinfo endpoint (/login/oauth/userinfo) decided whether to limit the groups claim to public organizations by re-parsing the Authorization header as an OAuth2 access token instead of using the scope of the credential that authenticated the request. When a public-only OAuth2 token was sent as a query parameter or form field, or a public-only personal access token was used, that scope came back empty and the claim listed the token owner's private organizations, teams and concealed memberships.

In Gitea, workflows triggered by a pull request review were read from the commit named in the review's commit_id, while fork restrictions were decided by the reviewed pull request, and the commit was not checked to belong to that pull request. A user with read access to a repository could place a commit of their own in it, through a fork pull request or an AGit push, and submit a review naming that commit on a pull request whose head branch is in the same repository. On instances with a runner serving the repository, the attacker's workflow then ran without approval, received the Actions secrets of the repository and its owner, and got a GITEA_TOKEN with write access to the repository.

When parsing an uploaded Helm chart, Gitea decompressed the archive and read every tar entry looking for `Chart.yaml` without limiting the decompressed size, and did so before checking the package size quota, which only considers the compressed upload size. A user with package write access could repeatedly upload small, highly compressed archives, making the server spend CPU time proportional to the decompressed size and degrading the availability of the Gitea instance.

The issue timeline API and the web issue page hid cross-reference events pointing at issues the reader cannot access, but not "dependency added" and "dependency removed" events. When a readable issue was linked as a dependency to an issue in an inaccessible repository, any reader of the first issue, including anonymous users of a public repository, received the linked issue's title, body, state, labels, poster and attachment names through the API, and its repository, number and title on the web page.

The repositories, stars and watching tabs of user profiles and the repository list of organization home pages included private repositories for every signed-in request without checking whether the request used a personal access token restricted to public resources (`public-only`). A holder of such a token could list the private repositories visible to the token's owner, and that user's stars and watches of private repositories.

The `/api/v1/admin` route group did not enforce the `public-only` restriction of personal access tokens. A public-only token with admin scope issued by a site administrator could list private organizations and all users' email addresses, create organizations, obtain runner registration tokens and create new site administrator accounts, the last of which persists after the token is revoked.

The `GITEA_TOKEN` of a Gitea Actions job authenticates as the `gitea-actions` system user, and the `/api/v1/user` email and GPG key endpoints accepted that user, so a job could register an email address and a GPG key on it; without required email confirmation the address is stored as activated. Commit verification treats a key without a real owner as the instance signing key, so any user who can run a workflow job could make commits signed with their own key show as trusted and signed by the instance.

The API routes for releases, release assets, milestones and repository labels did not reject changes to archived repositories. A user with write access to an archived repository, or a holder of such a user's write-scoped token, could replace or delete release assets while keeping their download URLs, delete releases and tags, and create, edit or delete milestones and labels of a repository meant to be read-only.

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 such a token with `write:organization` belonging to an owner of a public organization, an attacker could register an organization-level runner and receive jobs of the organization's private repositories with Actions enabled, including workflow content, Actions secrets and variables, and a task token with access to the private repository.

`GET /api/v1/users/{username}/heatmap` computed the contribution heatmap with the repository access of the token owner and ignored the public-only restriction of the access token, unlike the activity feed endpoints. A holder of a user's public-only token could read contribution counts and their 15-minute time buckets stemming from that user's activity in private repositories.

Legacy (v1 to v3) Actions artifact uploads stored the request's `Content-Encoding` header unchecked in the column served as the artifact's `Content-Type` on download, and a value starting with `video/` or `audio/` also removed the sandboxing Content-Security-Policy. A user who can run an Actions job could upload an artifact that a browser renders as HTML on the Gitea origin when the direct artifact download URL is opened, and the URL is reachable anonymously on public repositories.

A vulnerability in Gitea Actions allows task tokens to authenticate to the REST API as a shared system user with a negative ID, which repository, organization, project and key filters treated as having no owner restriction, and the token carried no API scope to restrict user-scoped routes. A user who can run a workflow could use the job's token with `GET /api/v1/user/repos` to list every repository on the instance, including private repositories of other users and organizations, with their metadata. Repository contents remained protected by per-repository permission checks.

In Gitea, seven API routes under /api/v1/users/{username} (followers, following, following/{target}, starred, subscriptions, keys, and gpg_keys) were registered without the individualPermsChecker middleware that enforces the visibility of the target user. An authenticated user could read the followers, following list, starred and watched repositories, and public SSH and GPG keys of a user with limited or private visibility. The issue was fixed in 1.27.3 and 28.0.0 and disclosed with 28.2.0.

When deleting a label, the repository ID from the request was compared against the organization ID of organization labels, and the two ID sequences overlap. A user with write access to a repository's issues could delete the labels of an organization with the same numeric ID as that repository. Labels are now deleted only within their own repository or organization.

Adding attachments to a release checked the repository and release of an attachment but not whether it was already linked to an issue or comment. A user with write access to a repository's releases, who knew the UUID of an attachment in that repository, could link it to a release. This exposed the file name, size, and download count of the attachment through the release and allowed the user to rename or delete it.

The visibility check of Gitea user profiles was applied to GET requests only, while POST /{username} (follow and unfollow) required only a signed-in user. Any authenticated user could therefore obtain the full name, location, website and description of a user with a private profile from the response. The issue was fixed in 28.1.0 and disclosed with 28.2.0.

Creating a draft release through the API returned an `assets` list that was built from a release without an ID, which matched every attachment that was not linked to a release. A user who could create a draft release in a repository therefore received the metadata (file name, UUID, upload time, size and download count) of issue and comment attachments of repositories they could not read, and of abandoned uploads.

GET /api/v1/user/subscriptions returned the metadata of every repository a user was watching without checking that the user still had access to it. A user who watched a private repository while having access, and later lost it, for example through a team permission downgrade, could still read its name, description, clone URLs, owner and counters. The issue was fixed in 1.27.0 and 28.0.0 and disclosed with 28.2.0.

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_PRINCIPALS_ALLOW=anything), a user could register another user's public key line as their own principal, or a holder of a certificate signed by that authority could list it, and then authenticate as the owner of that key through the HTTP signature API and the built-in SSH server. Instances that do not trust a user certificate authority are not affected.

The Gitea web handlers for adding and removing reactions on issues and comments did not refuse locked issues for users without write access, although the API did. A signed-in user who could read an issue could therefore add or remove reactions on a locked issue and its comments, bypassing the interaction restriction of the lock. Only reactions were affected; no content could be changed.

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 their repository changed. No other repository settings were reachable through this route.

The Gitea Actions artifact v4 (Twirp) handlers read the whole request body into memory without a size limit. A user who can run a workflow and obtains the runner token of that run could send an oversized request to the artifact service and exhaust the memory of the server, which terminates the Gitea process. The request body is now limited to 1 MiB.

Requesting /{username}/-/repositories for an individual user instead of an organization made the organization home handler dereference a nil organization and panic. The request needs no authentication and no special configuration. The server answered with an HTTP 500 error and logged a panic for each request; the fix returns 404 for individual users.

The Gitea OpenID association callback in the security settings accepted a positive OpenID 2.0 assertion without checking that the signed-in user had started the linking. Because OpenID 2.0 allows unsolicited assertions, an attacker-controlled OpenID provider could attach the attacker's identity to the account of a signed-in victim who opened a crafted link, and the attacker could then sign in as the victim through OpenID login, which does not apply the local TOTP or WebAuthn checks. The callback now requires a time-limited `state` value bound to the user.

Gitea's web attachment handler skips its cross-repository ownership check for attachments created before 16 January 2026 and checks permissions against the repository named in the request URL instead. An unauthenticated attacker who knows a private attachment's UUID can request it through a public repository's attachment path and retrieve its contents.

When OpenID sign-in is enabled, Gitea processes unauthenticated assertion parameters and sends an HTTP POST request to the caller-supplied OpenID provider endpoint during verification. An attacker controls the destination and much of the form body, allowing interaction with internal HTTP services reachable from the Gitea server.

Gitea's collaboration access-mode endpoint accepts the Owner access mode from an authenticated repository collaborator with Admin access. The collaborator can promote their effective permissions from Admin to Owner and then perform owner-only operations, including transferring the repository to their own account.

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 information, causing route-level token scope checks to be skipped.

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 and organization secrets available to that event.

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 load executable filter files. On deployments using a susceptible external renderer such as pandoc, a user who can place a filter file at an accessible path can cause it to execute as the Gitea service account; the public repository markup endpoint itself can be reachable without 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 a session and link an attacker-controlled identifier. The attacker can then sign in through that identifier without the victim's password or second factor, and a password change does not remove the link.

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.

Gitea's organization repository-creation API requires write:organization but omits the write:repository token scope enforced by other repository-creation routes. A personal access token or OAuth application token without repository-write scope can therefore create organization-owned repositories if the authorizing user has permission to do so. This bypasses the token's delegated scope boundary while remaining subject to the user's organization permissions.

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 initial GitLab migration version probe uses an HTTP client without a timeout and does not attach the migration task's cancellation context. An authenticated user who can start migrations can target an attacker-controlled server that keeps the response open indefinitely. The request continues after task cancellation and can exhaust the migration worker pool, preventing other migrations from progressing.

Gitea's repository-side team-link API allows a repository administrator who is not an organization owner to attach organization teams to a repository despite RepoAdminChangeTeamAccess being disabled. The endpoint does not enforce the organization's restriction on repository administrators changing team access.

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.