CVE-2026-110311: 
Gitea vulnerability analysis and mitigation

CVE-2026-110311 is an information disclosure vulnerability in Gitea's draft release API that exposes instance-wide attachment metadata from private repositories and abandoned uploads to any authenticated user who can create a draft release. It affects Gitea versions 1.22.0 through 28.1.0 (inclusive) and was disclosed on October 18, 2026. The vulnerability was discovered by open-source maintainer Daniel Roe while building a cross-forge API client. It carries a CVSS v3.1 base score of 4.3 (Moderate) (GitHub Advisory).

The root cause (CWE-200: Exposure of Sensitive Information to an Unauthorized Actor) lies in the order of operations within services/release/release.go. When CreateRelease() is called, it invokes createTag(), which calls rel.LoadAttributes(ctx) before the release row is inserted into the database — meaning rel.ID is 0 at that point. The subsequent GetReleaseAttachments() query uses IN ("release_id", sortedRels.ID), which resolves to release_id IN (0). Because issue and comment attachments are stored with release_id = 0, every such attachment on the entire instance matches this query and is returned in the API response's assets array. This logic was introduced by commit 28f9b313b (v1.22.0) when LoadAttributes() was moved to the top of createTag() to support archived-repo checks. Published releases are unaffected because the notifier's NewRelease() re-calls LoadAttributes() after the database insert, resetting the attachment list (GitHub Advisory).

Exploitation allows any authenticated Gitea user with a repository (sufficient to create a draft release) to enumerate attachment metadata — including file names, UUIDs, upload timestamps, file sizes, and download counts — from all issue and comment attachments across the entire instance, including those belonging to private repositories they cannot read, as well as abandoned uploads. On public Gitea instances, the scale of exposure can be significant: the reporter observed approximately 8,000 leaked entries from gitea.com and ~148,000 entries (~41 MB) from Codeberg in a single API request. File contents are not exposed, as the browser_download_url, /attachments/ endpoint, and API asset route all return 404 for unauthorized requesters (GitHub Advisory).

No public proof-of-concept exploit code or exploit kits have been identified, and there is no evidence of in-the-wild exploitation. The vulnerability requires only a low-privilege authenticated account with the ability to create a draft release (i.e., any registered user with a repository on the instance). The EPSS score is reported as 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog (Feedly, GitHub Advisory).

1. Obtain an account: Register or log in to a target Gitea instance running version 1.22.0–28.1.0. Any account with a repository is sufficient.
2. Create a repository (if not already present): The attacker needs at least one repository in which they have release-creation permissions.
3. Send a draft release creation API request: Issue a POST request to the Gitea API endpoint for creating a release with draft: true, e.g.:

   POST /api/v1/repos/{owner}/{repo}/releases
   Authorization: token <attacker_token>
   Content-Type: application/json
   
   {"tag_name": "recon-tag", "draft": true, "name": "recon"}

4. Parse the assets array in the response: The API response will include an assets list populated with metadata (file name, UUID, size, upload time, download count) for every issue/comment attachment on the instance that has no linked release — including those from private repositories the attacker cannot access.
5. Enumerate at scale: Repeat or automate the request to collect the full metadata inventory. A single request can return tens of thousands of entries on large instances (GitHub Advisory).

• Network/API Logs: Unusual or repeated POST requests to /api/v1/repos/<owner>/<repo>/releases with "draft": true in the request body, particularly from accounts that do not normally create releases or from accounts with minimal repository activity.
• Response Size Anomaly: API responses to draft release creation that are abnormally large (kilobytes to megabytes) compared to expected release creation responses, indicating the assets array was populated with instance-wide attachment metadata.
• Access Patterns: A single user account creating multiple draft releases in rapid succession across different repositories, potentially as a reconnaissance pattern to collect attachment metadata.

Gitea has released version 28.2.0 (released October 18, 2026), which includes the fix via pull requests #39743 (main branch) and #39752 (v28 backport). The fix corrects the LoadAttributes() call order so that attachment loading only occurs after the release row has been inserted and has a valid ID. Administrators should upgrade to Gitea 28.2.0 or later as soon as possible. No configuration-based workaround is available; upgrading is the only remediation (Gitea Release, Fix PR #39743, Backport PR #39752).

The vulnerability was discovered and responsibly disclosed by Daniel Roe, an open-source maintainer building a cross-forge TypeScript API client, who noted the leak was found incidentally while recording API fixtures. The Gitea team acknowledged and patched the issue promptly, with the fix merged on October 12, 2026 and the patched release (28.2.0) published on October 18, 2026. Coverage appeared on Linuxiac, which reported on the nine security vulnerabilities fixed in Gitea 28.2.0 (Linuxiac, GitHub Advisory).