| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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'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 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 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. |
| 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'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 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 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 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. |
| In Gitea before 1.25.2, /api/v1/user has different responses for failed authentication depending on whether a username exists. |
| Gitea before 1.25.2 mishandles authorization for deletion of releases. |
| Gitea before 1.23.0 allows attackers to add attachments with forbidden file extensions by editing an attachment name via an attachment API. |
| In Gitea before 1.22.5, branch deletion permissions are not adequately enforced after merging a pull request. |
| Gitea before 1.22.3 mishandles access to a private resource upon receiving an API token with scope limited to public resources. |
| 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.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. |
| In Gitea before 1.20.1, a forbidden URL scheme such as javascript: can be used for a link, aka XSS. |
| Gitea before 1.17.3 does not sanitize and escape refs in the git backend. Arguments to git commands are mishandled. |
