Advisories for Golang/Code.gitea.io/Gitea package

Me again. Gitea's built-in 3D file viewer (powered by Online3DViewer) is vulnerable to stored cross-site scripting (XSS) through crafted .gltf files. When a glTF file declares an unsupported required extension, Online3DViewer generates an error message containing the extension name and Gitea inserts it into the DOM using innerHTML without sanitization. An attacker who can push a .gltf file to any repository can execute arbitrary JavaScript in the context of any …

Many authenticated self routes under /api/v1/user/… do not enforce the public-only token restriction. As a result, a token or OAuth grant marked public-only, but otherwise carrying the route-required read/write scope category, can access or modify private account resources through self routes. The canonical private-user endpoint correctly rejects the same tokens, for example GET /api/v1/users/{privateUser} returns 403. The bypass exists because the generic /api/v1/user route group requires user scope and reqToken(), …

The API endpoint POST /api/v1/repos/{owner}/{repo}/forks only checks IsOrgMember() when a user forks a repository into an organization, but does not check CanCreateOrgRepo(). The web UI fork handler correctly checks both. This allows a read-only organization member — in a team with can_create_org_repo=false — to create repositories in the organization namespace via the API. The attacker receives full admin permissions on the forked repository, can enable Actions, push arbitrary workflow files, …

PR #37698 added checkDownloadTokenScope to /raw/, /media/, and attachment download web endpoints. The /archive/* endpoint (repo.Download in routers/web/repo/repo.go:372) was not included in the fix. This endpoint accepts OAuth2 tokens via webAuth.AllowOAuth2 (registered at routers/web/web.go:1649-1652) but does not call checkDownloadTokenScope or CheckRepoScopedToken. A personal access token with any non-repository scope (e.g., read:issue or read:misc) can download full repository archives (zip/tar.gz) of private repositories the token owner has access to.

Gitea fails to enforce OAuth2 access token scopes when the token is submitted via HTTP Basic authentication instead of a Bearer token. An OAuth2 application granted only read:user can use the same token as Authorization: Basic base64(<token>:x-oauth-basic) and perform write actions, including modifying profiles, adding email addresses, creating repositories, and deleting repositories as the authorizing user.

Three Gitea API endpoints — GET /repos/{owner}/{repo}/issue_templates, GET /repos/{owner}/{repo}/issue_config and GET /repos/{owner}/{repo}/issue_config/validate — read files from the repository's Code default branch (.gitea/ISSUE_TEMPLATE/* and issue_config.yaml) and return their contents, but are registered without the reqRepoReader(unit.TypeCode) authorization middleware that every sibling Code-tree endpoint in the same route group carries. A user who has access to a private repository through any single repository unit (for example an organization team granted only the Issues …

Two related issues in the token public-only scope enforcement introduced by PR #32204 (CVE-2025-68941 fix). A public-only scoped API token can access private organization data.

Gitea v1.26.1 enforces repository-scoped access-token permissions on repository operations. In the Git Smart HTTP path, however, this check runs only when the token is presented via HTTP Basic authentication — CheckRepoScopedToken() returns early unless ctx.IsBasicAuth is true — so the same token sent as Authorization: Bearer <token> bypasses the scope check entirely. As a result, a PAT or OAuth2 token presented as a Bearer credential can clone or fetch private …

Any authenticated low-privilege user with read access to a repository can push arbitrary commits directly to that repository, bypassing all write-access checks.

The built-in SSH server currently advertises a number of key exchange, MAC, and host key algorithms that are considered weak or broken. The defaults should be tightened so a fresh installation passes a baseline SSH security audit out of the box.

Gitea may send release notification emails for private repositories to users whose access has been revoked. When a repository is changed from public to private, users who previously watched the repository may continue to receive release notifications, potentially disclosing release titles, tags, and content.

Gitea does not properly verify repository context when deleting attachments. A user who previously uploaded an attachment to a repository may be able to delete it after losing access to that repository by making the request through a different repository they can access.

In Gitea before 1.25.2, /api/v1/user has different responses for failed authentication depending on whether a username exists.

In Gitea before 1.21.2, an anonymous user can visit a private user's project.

In Gitea before 1.20.1, a forbidden URL scheme such as javascript: can be used for a link, aka XSS.

Gitea before 1.22.2 sometimes mishandles the propagation of token scope for access control within one of its own package registries.

Gitea before 1.25.2 mishandles authorization for deletion of releases.

Gitea before 1.22.3 mishandles access to a private resource upon receiving an API token with scope limited to public resources.

Gitea before 1.21.8 inadvertently discloses users' login times by allowing (for example) the lastlogintime explore/users sort order.

In Gitea before 1.22.5, branch deletion permissions are not adequately enforced after merging a pull request.

Gitea before 1.22.2 allows XSS because the search input box (for creating tags and branches) is v-html instead of v-text.

Gitea before 1.23.0 allows attackers to add attachments with forbidden file extensions by editing an attachment name via an attachment API.

Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Gitea Gitea Open Source Git Server allows Stored XSS.This issue affects Gitea Open Source Git Server: 1.22.0.

The git hook feature in Gitea 1.1.0 through 1.12.5 allows for authenticated remote code execution.

In Gitea through 1.17.1, repo cloning can occur in the migration function.

Open Redirect in GitHub repository go-gitea/gitea prior to 1.19.4.

In Gitea before 1.16.9, it was possible for users to add existing issues to projects. Due to improper access controls, an attacker could assign any issue to any project in Gitea (there was no permission check for fetching the issue). As a result, the attacker would get access to private issue titles.

Cross-site Scripting (XSS) - Stored in GitHub repository go-gitea/gitea prior to 1.16.9.

Gitea 1.7.0 and earlier is affected by: Cross Site Scripting (XSS). The impact is: Attacker is able to have victim execute arbitrary JS in browser. The component is: go-get URL generation - PR to fix: https://github.com/go-gitea/gitea/pull/5905. The attack vector is: victim must open a specifically crafted URL. The fixed version is: 1.7.1 and later.

Gitea 1.7.2, 1.7.3 is affected by: Cross Site Scripting (XSS). The impact is: execute JavaScript in victim's browser, when the vulnerable repo page is loaded. The component is: repository's description. The attack vector is: victim must navigate to public and affected repo page.

Gitea before 1.8.0 allows 1FA for user accounts that have completed 2FA enrollment. If a user's credentials are known, then an attacker could send them to the API without requiring the 2FA one-time password.

Gitea before 1.16.7 does not escape git fetch remote.

An SSRF vulnerability in webhooks in Gitea through 1.5.0-rc2 and Gogs through 0.11.53 allows remote attackers to access intranet services.

Gitea version 1.6.2 and earlier contains a Incorrect Access Control vulnerability in Delete/Edit file functionallity that can result in the attacker deleting files outside the repository he/she has access to. This attack appears to be exploitable via the attacker must get write access to "any" repository including self-created ones. This vulnerability appears to have been fixed in 1.6.3, 1.7.0-rc2.

An arbitrary file deletion vulnerability in Gitea v1.16.3 allows attackers to cause a Denial of Service (DoS) via deleting the configuration file.

Open Redirect on login in GitHub repository go-gitea/gitea prior to 1.16.5.

The avatar middleware in Gitea before 1.13.6 allows Directory Traversal via a crafted URL.

Improper Authorization in GitHub repository go-gitea/gitea prior to 1.16.4.

Gitea before 1.5.4 allows remote code execution because it does not properly validate session IDs. This is related to session ID handling in the go-macaron/session code for Macaron.

An issue exsits in Gitea through 1.15.7, which could let a malicious user gain privileges due to client side cookies not being deleted and the session remains valid on the server side for reuse.

An Authentication Bypass vulnerability exists in Gitea before 1.5.0, which could let a malicious user gain privileges. If captured, the TOTP code for the 2FA can be submitted correctly more than once.

Gitea 1.12.x and 1.13.x before 1.13.4 allows XSS via certain issue data in some situations.