Gitea Open Source Git Server

Cross-repository information disclosure and cross-task tampering in Gitea's self-hosted Git server (fixed in v1.26.2) arises from an HMAC signature ambiguity in the Actions Artifacts V4 signed-URL scheme, letting an authenticated low-privilege user reuse a validly signed URL outside its intended repository or task context. An attacker with access to a single Actions task can read private artifacts belonging to other repositories and write upload-state for tasks they do not own, crossing the repository trust boundary (CVSS 9.6, scope-changed). There is no public exploit identified at time of analysis, and it is not listed in CISA KEV.

Authorization bypass in Gitea's Gitea Actions fork pull-request approval gate lets a low-privileged contributor permanently defeat the maintainer approval step that normally guards workflow execution on fork PRs, so that after the initial gate is subverted the attacker's workflow code runs against the repository's CI runners and secrets. CVSS is 8.9 (high) with a scope change and high integrity/availability impact; no public exploit has been identified at time of analysis, but a vendor patch (v1.26.4) is available. The flaw is classed as CWE-285 (Improper Authorization) and was self-reported by the Gitea project.

Authentication bypass in Gitea's Git LFS (Large File Storage) SSH handling allows a low-privileged authenticated user to read files from private repositories they should not access by supplying a malformed SSH sub-verb, per the Gitea security advisory GHSA-7wvc-rvp7-w99x. Because the flaw crosses a security boundary (CVSS scope change) it exposes confidential repository contents without any integrity or availability impact. No public exploit has been identified at time of analysis, and it is not listed in CISA KEV, but a vendor patch is available in Gitea 1.26.4.

Improper authorization on OAuth sign-in callback silently re-enables administrator-disabled accounts

Unauthenticated ReDoS via CODEOWNERS pattern matching allows denial of service

Notification API leaks private issue metadata after access revocation

Server-Side Request Forgery (SSRF) via HTTP redirect in Gitea's repository migration feature affects all versions through 1.25.4, allowing an authenticated attacker to coerce the Gitea server into issuing HTTP requests to arbitrary internal network destinations by supplying a crafted migration URL that redirects to an internal address. The CVSS score of 6.5 (C:H) reflects that successful exploitation can expose sensitive internal service responses - including cloud metadata endpoints, internal APIs, or other intranet services - to the attacker. No public exploit or CISA KEV listing has been identified at time of analysis; a vendor patch is available in v1.26.3 and v1.26.4.

Broken authorization in Gitea (self-hosted Git service) versions up to and including 1.26.2 lets a user who holds general repository access but has NOT been granted the Code unit permission read private source content by reusing Git LFS objects to authorize otherwise-restricted source objects. The flaw (CWE-639, tracked as GHSA-2m9v-5q2g-58vq) enables horizontal privilege escalation to confidential code within a repository. There is no public exploit identified at time of analysis and it is not listed in CISA KEV, but a vendor patch shipped in 1.26.3.

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.

Gitea versions before 1.26.0 do not fail closed on bufio.Scanner errors while processing pre-receive hook input, allowing oversized input to bypass branch-protection checks.

Gitea versions before 1.25.5 accept malformed or injected forwarded-proto values when detecting public URLs, allowing spoofed canonical URL generation.

Gitea 1.25.5 caches a branch-specific write-permission result across multiple refs in one pre-receive hook session, allowing a per-branch maintainer-edit grant to be reused for other refs and escalate to full repository write access.

Broken access control in Gitea's Composer package registry (versions up to and including 1.26.1) lets remote attackers read private or internal Composer package source links they should not be authorized to see, leaking internal repository/source metadata. The flaw is a missing-authorization (CWE-862) issue reported by the Gitea project itself and fixed in v1.26.2; no public exploit identified at time of analysis, and it is not listed in CISA KEV. With a CVSS 3.0 base score of 8.2 driven by high confidentiality impact, the practical effect is unauthorized disclosure of otherwise-private package sourcing information.

Gitea's repository RSS and Atom feed endpoints fail to enforce API token scope checks, exposing private repository commit metadata to any holder of a valid but under-privileged API token. Versions up to and including 1.26.2 are affected; the flaw is classified as CWE-863 (Incorrect Authorization) with a CVSS score of 4.3. No public exploit code or CISA KEV listing exists at time of analysis; vendor-released patches are available in v1.26.3 and v1.26.4.

Gitea versions before 1.25.5 allow draft release data or attachments to be accessed without the required write permission.

Gitea versions before 1.25.5 allow a user to change another user's primary email address.

Gitea versions before 1.25.5 do not enforce a timeout on git grep searches, allowing expensive searches to consume server resources.

Gitea versions before 1.25.5 do not use the migration HTTP transport for LFS push and sync mirror operations, bypassing the configured migration transport protections for those LFS requests.

Gitea versions before 1.25.5 do not persist the OAuth2 PKCE S256 challenge method correctly during authorization, allowing token exchange without the expected verifier check.

Gitea versions before 1.25.5 do not consistently enforce OAuth2 authorization code expiry and single-use behavior during token exchange.

Gitea versions before 1.25.5 look up tracked-time entries by time ID without scoping the lookup to the issue in the request URL, allowing deletion attempts to target entries from another issue.

Gitea versions before 1.25.5 mishandle path resolution during template repository generation, allowing template processing to read or write through symlinked or otherwise non-regular paths.

Gitea versions before 1.25.5 have insufficient visibility checks in organization permission APIs for hidden members and private organizations.

Gitea 1.26.2 allows unauthorized users to access labels of private organizations.

Gitea versions before 1.25.5 have insufficient permission checks for updating or rebasing pull request branches.

Gitea 1.26.2 allows fork synchronization to continue after a parent repository changes from public to private, exposing data to a fork that should no longer be authorized.

Server-side request forgery in Gitea versions up to and including 1.26.2 lets authenticated users abuse incomplete allow-list filtering in the webhook and repository-migration features to coerce the server into making requests to internal or otherwise restricted network destinations. Because the existing SSRF protection is incomplete rather than absent, attackers can craft addresses that bypass the allow-list checks to reach services that should be unreachable from outside. No public exploit identified at time of analysis, and the flaw is not listed in CISA KEV; a vendor patch is available in Gitea 1.26.3.

Gitea versions before 1.25.5 lack validation constraints for repository creation fields, including length-limited template fields and trust model or object format values.

Gitea versions before 1.25.5 have insufficient permission checks when listing tracked time entries.

Reverse-proxy authentication bypass in the official Gitea Docker image (versions up to and including 1.26.2) allows any source IP to impersonate arbitrary users because the image ships with REVERSE_PROXY_TRUSTED_PROXIES=* by default. When an operator enables reverse-proxy header authentication (e.g. X-WEBAUTH-USER), the wildcard trust list means Gitea accepts those identity headers from any client rather than only from a trusted front-end proxy, granting full account takeover including administrator access. No public exploit has been identified at time of analysis, and the issue is patched in Gitea 1.26.3.

TOTP two-factor authentication replay in Gitea 1.5.0 through 1.26.2 lets a captured valid one-time code be accepted multiple times instead of being invalidated after first use, weakening 2FA on both the web login flow and the Basic Auth X-Gitea-OTP header path. An attacker who observes a legitimate TOTP code (via interception, shoulder-surfing, or logging) can replay it within its validity window to authenticate as the victim. There is no public exploit identified at time of analysis and it is not listed in CISA KEV; the flaw is fixed in Gitea 1.26.3.