| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Gitea versions up to and including 1.26.1 allow Git smart HTTP requests authenticated with bearer tokens to bypass repository token scope checks. |
| SSRF via HTTP Redirect in Repository Migration |
| Notification API leaks private issue metadata after access revocation |
| Unauthenticated ReDoS via CODEOWNERS pattern matching allows denial of service |
| Improper authorization on OAuth sign-in callback silently re-enables administrator-disabled accounts |
| LFS authentication bypass via malformed SSH sub-verb allows unauthorized read access to private repositories |
| Permanent Fork PR Workflow Approval Gate Bypass |
| Gitea Actions Artifacts V4 signed URL HMAC ambiguity allows cross-repository artifact read and cross-task upload-state write |
| 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 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 validate ownership when toggling OpenID URI visibility. An authenticated user may be able to change the visibility settings of other users' OpenID identities. |
| 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 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'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 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. |
| 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 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. |
