| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Privilege Escalation via Access Token Scope Escalation in API |
| Gitea Remember-Me Token Theft Not Invalidating Attacker Session |
| Cross-repository IDOR in issue-dependency removal lets an attacker tamper with and comment on private repos they cannot access |
| Branch Protection Bypass via PR Retargeting Preserves Stale `official` Approval Flag |
| Webhooks created by a collaborator keep firing after their repo access is revoked → ongoing real-time exfiltration of private repo content (incomplete revocation cleanup in `DeleteCollaboration`) |
| Repository Visibility Manipulation via Git Push Options |
| Internal API HTTP client hardcodes InsecureSkipVerify:true with no config override (CWE-295) |
| Private org member list leaked via /members API endpoint — incomplete fix for PR #38145 |
| Release attachment extension allowlist bypass via web release edit form (variant of CVE-2025-68939) |
| ParseAcceptLanguage quadratic-time DoS via Locale middleware on unauthenticated requests |
| Fork-PR Actions task can read a third private repository via the collaborative-owner branch (missing fork-PR guard) |
| 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 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. |
