CVE-2026-110494: 
Gitea vulnerability analysis and mitigation

CVE-2026-110494 is an authorization bypass vulnerability in Gitea's AddReleaseAttachments function that allows authenticated users with release write access to re-link issue-bound attachments to releases they control. Affected software is Gitea (package gitea.dev) versions up to and including 28.1.0; version 28.2.0 contains the fix. The vulnerability was disclosed on October 18, 2026, and is classified as Moderate severity with a CVSS v3.1 base score of 6.3 (GitHub Advisory).

The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key): the AddReleaseAttachments function in models/repo/release.go (line 181) validates that an attachment belongs to the same repository and is not already linked to another release, but omits the check for whether the attachment is already linked to an issue (IssueID != 0). This asymmetry was introduced when the CVE-2026-57886 fix added validateAttachmentForIssue to issue and comment attachment handlers but did not apply the equivalent IssueID check to the release attachment handler. An attacker exploits this by supplying a known attachment UUID in a release attachment linking request, bypassing the missing guard. UUID enumeration is infeasible (v4, 128-bit random), so the attacker must obtain the UUID through side channels such as notification emails, webhook payloads, RSS/Atom feeds, browser history, or Markdown content (GitHub Advisory, Fix PR #39839).

A successful attack exposes the filename, UUID, size, and download count of the targeted issue attachment through the release page and API endpoint (GET /api/v1/repos/{owner}/{repo}/releases/{id}/assets), which may reveal sensitive information embedded in filenames. Beyond metadata disclosure, the attacker can permanently rename or delete the attachment — including its physical file from storage — in a single HTTP request, causing irreversible data loss and integrity violations. File content download remains protected because the download handler checks IssueID before ReleaseID, so an attacker without issue read access cannot retrieve the file's contents (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported. The EPSS score is 0.0 and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires an authenticated account with release write permission in the target repository and prior knowledge of a valid attachment UUID, limiting the practical attack surface. The vulnerability was reported by researcher @manus-pi and disclosed responsibly alongside the patch release (GitHub Advisory, Feedly).

1. Obtain release write access: Acquire an authenticated Gitea account that has been granted write access to the Releases unit of a target repository, without necessarily having issue read/write access.
2. Obtain a target attachment UUID: Identify the UUID of an issue attachment in the same repository through a side channel — e.g., notification emails, webhook payloads, RSS/Atom feeds, browser history, or Markdown source viewed before permission changes.
3. Craft the attachment link request: Send an authenticated HTTP request to the Gitea API or web interface to add the known UUID as an attachment to a release the attacker controls (e.g., POST /api/v1/repos/{owner}/{repo}/releases/{id}/assets or via the release edit form).
4. Exploit the missing IssueID check: Because AddReleaseAttachments does not verify IssueID != 0, the request succeeds and the issue-bound attachment is re-linked to the attacker's release.
5. Disclose metadata: View the release page or query GET /api/v1/repos/{owner}/{repo}/releases/{id}/assets to retrieve the attachment's filename, size, and download count.
6. Rename or delete the attachment: Use the release edit interface to rename or permanently delete the attachment, removing both the database record and the physical file from storage (GitHub Advisory).

• Network: Unexpected API calls to POST /api/v1/repos/{owner}/{repo}/releases/{id}/assets or equivalent web endpoints supplying attachment UUIDs that belong to issues rather than the release being edited; repeated GET /api/v1/repos/{owner}/{repo}/releases/{id}/assets queries from accounts with release-only permissions.
• Logs: Gitea access logs showing a user with release write (but not issue) access successfully linking an attachment UUID to a release, followed by rename or delete operations on that attachment; audit log entries for attachment deletion where the deleting user has no issue permissions.
• File System: Unexpected disappearance of attachment files from the Gitea attachment storage directory corresponding to issue attachments that were not explicitly removed by issue participants.

Upgrade Gitea to version 28.2.0 or later, which adds the missing IssueID != 0 check to AddReleaseAttachments in models/repo/release.go, symmetric with the existing check in validateAttachmentForIssue (Gitea Release v28.2.0, Fix PR #39839, Backport PR #39847). No interim code-level mitigation exists; as a configuration workaround, restrict the Releases write permission exclusively to users who also hold issue read/write access in the same repository, eliminating the permission gap that enables the attack (GitHub Advisory).