Gitea AuthBypass: Unauthorized Draft Release Attachment Access via UUID

Vulnerability Overview Vulnerability Name: Missing Authorization and Authorization Bypass Through User-Controlled Key and Incorrect Permission Assignment for Critical Resource and Exposure of Sensitive Information to an Unauthorized Actor in code.gitea.io/gitea Vulnerability Description: Gitea's draft release access control is enforced only on the API endpoints and , but not on the UUID-based web endpoints , , , and . Anyone, including unauthenticated callers, who obtains the UUID of an attachment associated with a draft release can indefinitely download its full content, even though the draft release itself is correctly hidden from lists and not accessible via ID-API lookup. Root Cause: The web handler only checks repository-level read permissions and never checks the flag. Scope Affected Versions: <= 1.26.4 Fixed Version: 1.27.0 Severity: 5.9 / 10 (Medium) CVSS v3 base metrics: - Attack vector: Network - Attack complexity: High - Privileges required: None - User interaction: None - Scope: Unchanged - Confidentiality: High - Integrity: None - Availability: None Remediation Recommended Patch: Extend the existing permission check in to also check write access for draft releases. Alternative Approach: could return the linked release object, eliminating the need for the caller to perform a second database read. POC Code Impact Vulnerability Class: Missing authorization on parallel code paths (CVE-862), where the same authorization check is ignored when added to separate handlers. This is an incomplete fix addressing CVE-2026-27660. Why this is an exploitable vulnerability and not merely a "misconfiguration": Gitea's draft release feature exists precisely to phase content until it is ready for public release. PR #36659 (CVE-2026-27660) explicitly stated "draft releases and their attachments require write access to view," and accordingly updated the security policies for and . However, the handler (accessible via three different routes, running on the same host and serving the same underlying attachment objects) was not updated. Consequently, the security policy promised to operators ("draft attachments are visible only to repo writers") is violated by the web URLs provided by the API. Maintainers cannot redefine this as "UUID is a capability token" because Gitea explicitly rejected such a model two months prior. The threat model is identical, differing only in the handler involved. Actual Data at Risk Draft releases are typically used for: Pre-release binaries (Windows MSI, macOS signed DMG, Linux RPM/DEB): Unauthorized downloading of unannounced builds. Security fix release candidates: Pre-release windows for downstream patching if binaries leak vulnerabilities. SECURITY.md, signing keys, third-party license packages: Supply chain reconnaissance. release-key public blob bundles: Key rotation attacks via external observation. Build artifacts: Published to draft tags via CI pipelines before release engineers decide to publish. CHANGELOG These are not hypothetical use cases. They are documented and intended uses of the draft release feature on every git forge. Real-World Attack Scenarios (Internal Leak Threat Model, Identical to CVE-2026-27660) 1. Browser "Copy Link": Causes URLs to leave the security boundary. Release engineers preparing the next release copy to test binaries on a clean VM, then paste them into Slack threads, Jira tickets, emails, QA systems, or commit messages ("binary: URL"). Anyone who subsequently views that channel (including former employees, revoked contractors, or anyone scanning public archives) can anonymously and indefinitely access the binaries without authentication. 2. Reverse Proxies or Observability Storage: Log URLs. nginx, Caddy, HAProxy, Cloudflare, Datadog, Splunk, ELK: any HTTP-instrumented pipeline records request paths. Anyone with log read access can extract UUIDs and download underlying attachments without authenticating to Gitea. For ELT pipelines copying logs to cloud storage or data lakes, read access can be very broad. 3. Browser History, Referer, Extension Telemetry: Once an authorized user downloads an attachment, URLs containing UUIDs exist in browser history, optional cloud-sync history (Chrome Sync, Edge Sync, Firefox Sync, recoverable any signed-in devices), browser extension telemetry, and any Referer sender header. URLs may be embedded in iframes or online ads. 4. Search Engines and Mirror Indexes: Internal sites, asset inventories, dependency scanners, SaaS supply chain tools indexing attachments if they follow will index draft URLs just like released ones. Thus, the time the URL is discoverable in indexes is equal to the indexing time. 5. Embedded Links in Public Content: Draft release attachment URLs pasted into issue comments, PR descriptions, wiki pages, or READMEs, rendered as clickable : visible to anyone reading that public page. Readers do not see the draft release itself, but clicking the link retrieves the attachment. Severity Calibration via Direc

Goal Reached Thanks to every supporter — we hit 100%!

Gitea AuthBypass: Unauthorized Draft Release Attachment Access via UUID

More from this source