Gitea CVE-2026-110494

The attacker must (1) hold write access to the releases of the target repository (PR:L / authenticated collaborator) and (2) already know the UUID of an existing attachment belonging to an issue or comment within that same repository. Exploitation is specifically the release attachment-linking operation (AddReleaseAttachments), which prior to v28.2.0 validated the attachment's repository and release association but failed to check whether the attachment was already linked to an issue or comment. Limiting factors: UUIDs are random and non-enumerable, so the attacker needs the exact UUID (typically via a leaked link or prior API access); the flaw is confined to the same repository; and only metadata (name, size, download count) is exposed plus rename/delete - no file content read beyond metadata is implied.

This is a genuinely medium/low priority issue, not an inflated high-CVSS item. The CVSS 3.1 base score of 6.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L) reflects an authenticated-user authorization flaw with only Low impact to each of confidentiality, integrity and availability, consistent with CWE-639 (Authorization Bypass Through User-Controlled Key / IDOR). Every exploitation signal points to low real-world urgency: EPSS is 0.15% (4th percentile), there is no CISA KEV listing (confirmed actively exploited: NO), and no public exploit identified at time of analysis. The attack requires an already-authenticated user holding write access to a repository's releases (PR:L), which bounds the attacker population to trusted collaborators rather than anonymous internet attackers. A key mitigating factor NOT fully captured by the AC:L rating is that the attacker must already know the random UUID of a target attachment in that repository - UUIDs are not enumerable, so AC:L is arguably optimistic and real exploitation depends on UUID leakage. The vector's AV:N is correct (the action occurs over the Gitea web/API interface), and C:L/I:L/A:L correctly map to disclosure of file metadata, renaming, and deletion. Note the input Tag 'Authentication Bypass' conflicts with the actual class of flaw: the user is already authenticated (PR:L), so this is an authorization/IDOR issue, not authentication bypass. Overall: patch on normal cadence; not an emergency.

A collaborator with write access to a repository's releases learns the UUID of an attachment that belongs to an issue or comment in the same repository (e.g. from a leaked link or API response). They call the release attachment-linking API with that UUID, causing the file to be linked to a release they control. They can now view the file's name, size and download count, and rename or delete the file. No public exploit code is known, and exploitation is bounded by needing the specific UUID and repo write access.