Gitea

Open redirect in Gitea's login flow allows external domain hijacking by bypassing the `urlIsRelative` validation in `modules/httplib/url.go` through a combination of directory traversal sequences and a backslash in the `redirect_to` parameter. All Gitea instances running version 1.25.4 and below are affected; a working proof-of-concept is publicly available in the GitHub Security Advisory. Exploitation enables phishing via trusted Gitea domains, OAuth/SSO authorization code theft, Referer-header leakage of sensitive parameters, and potential cache poisoning — no public exploit identified as confirmed actively exploited (CISA KEV absent).

Stored cross-site scripting in Gitea 1.25.x affects the built-in 3D file viewer (Online3DViewer integration) where a crafted .gltf file with an unsupported extension name in extensionsRequired is rendered into the DOM via innerHTML without sanitization. Any low-privileged user who can push a file to a repository (including a public fork) can compromise the session of any user who later views the file, enabling token theft and full account takeover. Publicly available exploit code exists (a working PoC is included in the GHSA-9cpj-qc93-vw8v advisory); no public exploit identified at time of analysis in CISA KEV.

Authorization bypass in Gitea versions 1.22.3 through 1.26.1 allows holders of `public-only` access tokens or OAuth grants to read and modify private account resources via `/api/v1/user/...` self routes, despite the public-only flag being designed to restrict tokens to public data. The flaw is a systemic scope-boundary failure across many self routes (SSH keys, emails, OAuth apps, Actions secrets/variables/runners, private repos, webhooks), publicly available exploit code exists in the form of reproducible Go PoCs in the advisory, and the issue represents an incomplete fix of CVE-2025-68941 in a different route family.

Authorization bypass in Gitea versions prior to 1.26.0 lets a read-only organization member create repositories in the organization namespace via the API fork endpoint, despite a team configuration that denies repository creation (can_create_org_repo=false). Because the fork creator receives admin rights on the resulting repo, the attacker can enable Actions and push a workflow that exfiltrates all organization-level CI/CD secrets (deploy keys, cloud credentials, API tokens). Publicly available exploit code exists in the GHSA advisory with a full step-by-step PoC; no public exploit identified at time of analysis beyond the reporter's reproduction.

Missing repository-unit authorization on three Gitea API endpoints allows authenticated users with only non-Code unit access (e.g., an Issues-only organization team member) to read `.gitea/ISSUE_TEMPLATE/*` and `issue_config.yaml` files from the Code default branch of a private repository. The CVSS score of 4.3 (PR:L, C:L) accurately reflects the narrow scope: exploitation is limited to those specific configuration files, not arbitrary source code. A proof of concept is publicly documented in the vendor advisory (GHSA-3fwp-p5rj-2pxf); no active exploitation is confirmed in the CISA KEV catalog at time of analysis.

Public-only scoped API tokens in Gitea bypass their declared scope constraints and expose private organization membership data through two distinct code defects in `routers/api/v1/api.go`: the `/user/orgs` route omits the `checkTokenPublicOnly()` middleware entirely, and the `checkTokenPublicOnly` function contains a Go switch-case logic flaw that skips the user-visibility check on multi-category routes. This is an incomplete remediation of CVE-2025-68941 introduced by PR #32204, affecting all Gitea instances running version 1.26.1 and earlier. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis, but the attack is trivially reproducible from the published advisory steps.

Authorization bypass in Gitea versions up to and including 1.26.1 allows any authenticated user with mere read access to push arbitrary commits directly to any repository they can view, including all public repositories on the instance. The flaw stems from the 'Allow edits from maintainers' pull request flag being trusted without verifying the PR submitter actually owns write access on the HEAD side, enabling reverse-fork PRs to grant unauthorized push rights to upstream targets. Publicly available exploit code exists (a working poc.py is attached to the advisory), and the issue is fixed in Gitea 1.26.2.

OAuth2 scope enforcement bypass in Gitea <= 1.26.1 allows any OAuth2 access token to perform write actions far beyond its granted scope when submitted via HTTP Basic authentication instead of as a Bearer token. A token issued with only `read:user` can modify user settings, add attacker-controlled emails, and create or delete the user's repositories, effectively nullifying the entire OAuth2 scope model for Basic-auth requests. No public exploit identified at time of analysis, but the advisory itself contains a full working PoC.

Authorization scope bypass in Gitea v1.26.1 and earlier allows authenticated users to use OAuth2/PAT Bearer tokens to perform Git Smart HTTP clone, fetch, and push operations on private repositories without holding the required read:repository or write:repository token scopes. The flaw stems from CheckRepoScopedToken() short-circuiting unless ctx.IsBasicAuth is true, while the same route accepts Bearer authentication. No public exploit identified at time of analysis beyond the reporter's PoC test in the GHSA advisory.

Gitea fails to validate repository ownership when linking attachments to releases, allowing users to attach files from one repository to releases in another.

Gitea's OpenID URI visibility controls lack proper ownership validation, allowing authenticated users to modify the visibility settings of other users' OpenID identities. This integrity bypass affects any Gitea instance where multiple users manage OpenID configurations, enabling account enumeration or information disclosure through unauthorized visibility changes. A patch is available to remediate this medium-severity vulnerability.

Gitea fails to validate repository ownership when deleting Git LFS locks, allowing users with write access to one repo to delete LFS locks in other repositories.

Gitea fails to enforce proper authorization checks when users attempt to cancel scheduled auto-merges through the web interface, allowing any user with pull request read access to cancel merge operations initiated by other users. This authorization bypass could disrupt automated workflows and merge processes across repositories. A patch is available to address this vulnerability.

Gitea's stopwatch API fails to re-validate repository access permissions, allowing revoked users to access sensitive information through active stopwatch sessions. An authenticated attacker with prior access to a private repository can enumerate issue titles and repository names even after their permissions have been removed. A patch is available to enforce proper access control validation.

Gitea's notification API fails to re-validate repository access permissions when retrieving notification details, allowing users with revoked access to private repositories to continue viewing issue and pull request titles through cached notifications. An authenticated attacker can exploit this to maintain visibility into sensitive repository content after their access has been removed. A patch is available.

Gitea does not properly validate project ownership in organization operations, allowing users with project write access to manipulate projects belonging to other organizations.

Gitea fails to properly validate repository ownership when processing attachment deletion requests, allowing an authenticated attacker to delete files from repositories they no longer have access to by routing deletion requests through a different accessible repository. This authorization bypass affects all users who have uploaded attachments to shared repositories and could result in loss of critical project documentation or resources. A patch is available to address this improper access control vulnerability.

Gitea may send release notification emails for private repositories to users whose access has been revoked. [CVSS 3.5 LOW]

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