Gitea CVE-2025-68938

Exploitation requires reaching Gitea's release-deletion API/web endpoint on an instance running a version before 1.25.2. The flaw is that Gitea does not correctly enforce who is authorized to delete releases, so a user without proper release-management permission on the target repository can perform the deletion. LIMITING FACTORS: realistically an attacker needs a valid Gitea account and API/network access to the target repository (despite the NVD vector listing PR:N, an authorization-bypass on this operation implies at least some authenticated foothold); the impact is confined to loss/removal of release data for repositories reachable by that account; and the issue is remediated in 1.25.2, so only unpatched instances are affected. No special non-default configuration is indicated by the description.

This is a medium-severity authorization flaw (CVSS 5.3) in Gitea's handling of release deletion (CWE-863, Incorrect Authorization). The real-world risk signals are mostly low-to-moderate and partly conflicting. EPSS is low at 0.38% (30th percentile), there is no CISA KEV listing (not confirmed actively exploited), and no public exploit was identified in the provided data - so this is not a widespread-exploitation emergency. However, the NVD CVSS vector contains notable inconsistencies with the vulnerability class that should be verified: the vector states PR:N (unauthenticated) and attributes the impact to availability (A:L, with C:N/I:N), yet an authorization-bypass bug on a release-deletion API almost certainly requires an authenticated account and the primary consequence is unauthorized DELETION of release data, which is an integrity impact rather than pure availability. Treat the PR:N and A:L designations with caution - they appear to overstate reachability (unauthenticated) while mischaracterizing the impact type (availability vs. integrity); verify the true privilege requirement with the vendor/PR. Net assessment: a legitimately exploitable but bounded authorization defect, best prioritized as a routine patch for internet-facing or multi-tenant Gitea instances rather than an urgent zero-day.

An attacker holding a low-privileged but valid Gitea account (or access to a repository where they lack release-management rights) issues an API request to delete one or more releases. Because Gitea mishandles the authorization check before 1.25.2, the deletion is permitted despite insufficient permissions, destroying release artifacts/metadata. No public exploit code was identified at time of analysis.