go-gitea/gitea

Gitea: Branch Protection Bypass via PR Retargeting Preserves Stale `official` Approval Flag

SSRF via HTTP Redirect in Repository Migration

Gitea Actions Artifacts V4 signed URL HMAC ambiguity allows cross-repository artifact read and cross-task upload-state write

Permanent Fork PR Workflow Approval Gate Bypass

LFS authentication bypass via malformed SSH sub-verb allows unauthorized read access to private repositories

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

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 allow Git LFS object reuse to authorize private source objects for users who have repository access but lack Code-unit access.

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 up to and including 1.26.1 have insufficient permission checks for Composer package source links, which can expose private or internal package source information.

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 up to and including 1.26.1 allow OAuth2 access token scope enforcement to be bypassed through HTTP Basic authentication.

Gitea versions up to and including 1.26.1 do not enforce repository-unit authorization on issue-template API endpoints.

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.

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 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 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 up to and including 1.26.2 allow repository RSS and Atom feed endpoints to bypass API access token scope checks, exposing private repository commit data to tokens without the required repository scope.

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 up to and including 1.26.1 allow the Allow edits from maintainers permission path to authorize commits to repositories that the user can read but should not be able to write.

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

Gitea versions before 1.26.0 allow API users to fork a repository into an organization without first passing the CanCreateOrgRepo check, which can expose organization secrets.

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 up to and including 1.26.1 do not apply public-only token filtering consistently to the user organization API, leaving an incomplete fix for CVE-2025-68941.

Gitea versions up to and including 1.25.4 allow redirect bypasses through raw or percent-encoded backslashes in redirect_to values.

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.

Gitea versions up to and including 1.26.2 have incomplete SSRF protection in webhook and migration allow-list filtering.

Gitea versions up to and including 1.26.1 allow repository archive downloads to bypass token scope checks on the web archive download endpoint.

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.

Gitea Docker image versions up to and including 1.26.2 use REVERSE_PROXY_TRUSTED_PROXIES=* by default, allowing any source IP to impersonate a user when reverse-proxy authentication headers such as X-WEBAUTH-USER are enabled.

Gitea versions from 1.5.0 before 1.26.3 have a TOTP single-use enforcement defect that allows a valid TOTP code to be accepted more than once across web two-factor authentication flows and the Basic Auth X-Gitea-OTP path.

Gitea does not properly validate repository ownership when linking attachments to releases. An attachment uploaded to a private repository could potentially be linked to a release in a different public repository, making it accessible to unauthorized users.

Gitea does not properly validate ownership when toggling OpenID URI visibility. An authenticated user may be able to change the visibility settings of other users' OpenID identities.

Gitea does not properly validate repository ownership when deleting Git LFS locks. A user with write access to one repository may be able to delete LFS locks belonging to other repositories.

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.

Gitea does not properly validate project ownership in organization project operations. A user with project write access in one organization may be able to modify projects belonging to a different organization.

Gitea's notification API does not re-validate repository access permissions when returning notification details. After a user's access to a private repository is revoked, they may still view issue and pull request titles through previously received notifications.

Gitea's stopwatch API does not re-validate repository access permissions. After a user's access to a private repository is revoked, they may still view issue titles and repository names through previously started stopwatches.

Gitea does not properly verify authorization when canceling scheduled auto-merges via the web interface. A user with read access to pull requests may be able to cancel auto-merges scheduled by other users.

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.

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.20.1, a forbidden URL scheme such as javascript: can be used for a link, aka XSS.

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

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

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

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.

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

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

Gitea before 1.25.2 mishandles authorization for deletion of releases.

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.

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 Jenkins Gitea Plugin 1.4.4 and earlier, the implementation of Gitea personal access tokens did not support credentials masking, potentially exposing them through the build log.

Gitea before 1.17.3 does not sanitize and escape refs in the git backend. Arguments to git commands are mishandled.

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 before 1.16.7 does not escape git fetch remote.

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.

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

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.

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.

Cross Site Scripting (XSS) vulnerability exists in Gitea before 1.5.1 via the repository settings inside the external wiki/issue tracker URL field.

Gitea before 1.4.3 is affected by URL Redirection to Untrusted Site ('Open Redirect') via internal URLs.

Gitea before 1.11.2 is affected by Trusting HTTP Permission Methods on the Server Side when referencing the vulnerable admin or user API. which could let a remote malisious user execute arbitrary code.

Cross Site Request Forgery (CSRF) vulnerability exists in Gitea before 1.5.2 via API routes.This can be dangerous especially with state altering POST requests.

Server Side Request Forgery (SSRF) vulneraility exists in Gitea before 1.7.0 using the OpenID URL.

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

Stack buffer overflow vulnerability in gitea 1.9.0 through 1.13.1 allows remote attackers to cause a denial of service (crash) via vectors related to a file path.

Gitea 0.9.99 through 1.12.x before 1.12.6 does not prevent a git protocol path that specifies a TCP port number and also contains newlines (with URL encoding) in ParseRemoteAddr in modules/auth/repo_form.go.

The git hook feature in Gitea 1.1.0 through 1.12.5 might allow for authenticated remote code execution in customer environments where the documentation was not understood (e.g., one viewpoint is that the dangerousness of this feature should be documented immediately above the ENABLE_GIT_HOOKS line in the config file). NOTE: The vendor has indicated this is not a vulnerability and states "This is a functionality of the software that is limited to a very limited subset of accounts. If you give someone the privilege to execute arbitrary code on your server, they can execute arbitrary code on your server. We provide very clear warnings to users around this functionality and what it provides.

An issue was discovered in Gitea through 1.11.5. An attacker can trigger a deadlock by initiating a transfer of a repository's ownership from one organization to another.

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.

Jenkins Gitea Plugin 1.1.1 and earlier did not implement trusted revisions, allowing attackers without commit access to the Git repo to change Jenkinsfiles even if Jenkins is configured to consider them to be untrusted.

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.

models/repo_mirror.go in Gitea before 1.7.6 and 1.8.x before 1.8-RC3 mishandles mirror repo URL settings, leading to remote code execution.

repo/setting.go in Gitea before 1.7.6 and 1.8.x before 1.8-RC3 does not validate the form.MirrorAddress before calling SaveAddress.

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.

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.

Gitea version prior to version 1.5.1 contains a CWE-200 vulnerability that can result in Exposure of users private email addresses. This attack appear to be exploitable via Watch a repository to receive email notifications. Emails received contain the other recipients even if they have the email set as private. This vulnerability appears to have been fixed in 1.5.1.

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.