gitea

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 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 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'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 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 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 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.

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

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

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 allows XSS because the search input box (for creating tags and branches) is v-html instead of v-text.

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.23.0 allows attackers to add attachments with forbidden file extensions by editing an attachment name via an attachment API.

Gitea before 1.25.2 mishandles authorization for deletion of releases.