Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
20 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Details Despite the validation within urlIsRelative in modules/httplib/url.go, an open redirect is still possible due to usage of directory traversal sequences plus a back-slash in the "redirectto" parameter. PoC When a user uses this URL to login: https://gitea.com/user/login?redirectto=/a/../\example.com They would be redirected to example.com upon a successful login to their gitea account. Impact Phishing: Attackers can use trusted domain links to redirect victims to credential-harvesting pages OAuth/SSO Token Theft: In authentication flows, authorization codes or tokens may leak via redirect Referer Leakage: Sensitive URL parameters may be exposed to attacker domains via the Referer header Cache Poisoning: In deployments with shared caches, malicious redirects may be cached and served to other users
Recommended action: Upgrade to 1.26.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 1.25.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 1.25.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 1.25.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 1.25.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 1.25.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 1.25.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 1.25.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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/repoform.go.
Recommended action: Upgrade to 1.12.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 1.13.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gitea before 1.17.3 does not sanitize and escape refs in the git backend. Arguments to git commands are mishandled.
Recommended action: Upgrade to 1.17.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Specific Go Packages Affected github.com/go-gitea/gitea/models
Recommended action: Upgrade to 1.7.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
models/repomirror.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.
Recommended action: Upgrade to 1.7.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Specific Go Packages Affected github.com/go-gitea/gitea/models
Recommended action: Upgrade to 1.5.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue was discovered in Gitea in which an attacker can trigger a deadlock by initiating a transfer of a repository's ownership from one organization to another.
Recommended action: Upgrade to 1.12.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Cross Site Scripting (XSS) vulnerability exists in Gitea before 1.5.1 via the repository settings inside the external wiki/issue tracker URL field.
Recommended action: Upgrade to 1.5.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 1.5.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gitea is a project to help users set up a self-hosted Git service. Server Side Request Forgery (SSRF) vulnerability exists in Gitea before 1.7.0 using the OpenID URL. Gitea can leak sensitive information about the local network through the error provided by the UI.
Recommended action: Upgrade to 1.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gitea is a project to help users set up a self-hosted Git service. Gitea before 1.11.2 is affected by Trusting HTTP Permission Methods on the Server Side when referencing the vulnerable admin or user API. This could allow a remote malicious user to execute arbitrary code.
Recommended action: Upgrade to 1.11.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gitea before 1.4.3 is affected by URL Redirection to Untrusted Site ('Open Redirect') via internal URLs.
Recommended action: Upgrade to 1.4.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.