Threat Intelligence Database

Public-only tokens bypass private-resource restrictions on `/api/v1/user` self routes

Gitea Notification API in versions prior to 1.26.4 leaks private issue and pull request metadata through the 'subject' field of notification threads after a user's access to a private repository has been revoked. While the 'repository' field is correctly nulled, the 'subject' field still exposes sensitive information such as issue titles, URLs, state, and comment activity. This allows users who lost access to continue observing ongoing activity on private issues or pull requests via notifications.

Gitea Actions Artifacts V4 signed URLs suffer from an HMAC signature ambiguity that allows an attacker with permission to run a Gitea Actions job to rewrite signed URLs. This enables unauthorized reading of artifacts from other repository tasks and unauthorized writing to other task artifact upload staging areas, including private repositories. The vulnerability arises because the HMAC input concatenates multiple fields without delimiters, allowing different URL parameter combinations to produce the same signature. This flaw affects versions from 1.22.0 up to but not including 1.26.2.

Gitea Actions contains a vulnerability in the fork pull request workflow approval gate that allows an attacker with a single unprivileged account and one-time maintainer approval on a benign fork PR to permanently bypass approval for all future fork PR workflow runs from that user on the same repository. This bypass occurs because the approval check only verifies if the user has any previously approved run in the repository, without considering the pull request, commit, or workflow contents. The vulnerability affects all Gitea versions from v1.20.0 onward and remains unpatched as of this disclosure.

A vulnerability in Gitea's SSH LFS sub-verb handling allows any authenticated SSH user to bypass access controls and obtain valid LFS credentials for private repositories they do not have permission to access. This flaw enables unauthorized read access to all LFS objects in any private repository on the instance. The issue arises because unknown LFS sub-verbs cause the permission check to incorrectly grant access. This affects Gitea versions from 1.23.0 up to but not including 1.26.3. No official patch or fix has been confirmed yet.

Gitea 1.25.4 and earlier versions prior to 1.26.4 contain a server-side request forgery (SSRF) vulnerability in the repository migration endpoint. The vulnerability arises because Gitea validates the initial migration URL to block internal addresses but does not re-validate URLs after following HTTP 302 redirects. This allows a low-privilege user to cause Gitea to access internal services by redirecting from an attacker-controlled server to internal IP addresses, effectively using Gitea as a proxy to access otherwise inaccessible internal resources.

Gitea versions up to and including 1.26.1 allow Git smart HTTP requests authenticated with bearer tokens to bypass repository token scope checks.

Gitea versions up to and including 1.26.2 contain a vulnerability that allows Git LFS object reuse to improperly authorize access to private source objects. This affects users who have repository access but do not have Code-unit access, potentially exposing sensitive data. The vulnerability is identified as CWE-639 (Authorization Bypass Through User-Controlled Key) and CWE-863 (Incorrect Authorization).

Gitea versions from 1.25.0 before 1.26.0 allow stored cross-site scripting through the extensionsRequired field in glTF files rendered by the 3D file viewer.

Gitea versions before 1.25.5 use release tag names and asset names as filesystem path components when dumping release assets, allowing specially crafted names to affect dump output paths.