CVE-2026-52799: Gogs Missing Authorization in Attachment Download
Gogs serves issue and release attachment files to anyone who knows the UUID, with no check that the requester can actually view the repository the attachment belongs to.
The problem
The `GET /attachments/:uuid` route in Gogs looks up an attachment by its UUID and streams the file directly to the caller. It never checks whether the caller has read access to the parent repository, issue, comment, or release.
When `REQUIRE_SIGNIN_VIEW = false` (the default), a completely unauthenticated attacker can download files attached to private repositories. Even with sign-in required, any authenticated user, regardless of repository permissions, can fetch the file if they know the UUID.
Proof of concept
# Unauthenticated download of a private-repo attachment
# Replace the UUID with any valid attachment UUID (e.g., obtained from a
# leaked URL, a public issue on the same instance, or brute-force).
curl -O http://gogs.example.com/attachments/f06d90f8-5b62-4c10-ac8d-f11fdf870b57
# Verify the repo itself is inaccessible (returns 404):
curl -I http://gogs.example.com/myadmin/private-repo
# HTTP/1.1 404 Not Found
# The attachment downloads successfully despite the 404 above.The handler in `internal/cmd/web.go` calls `GetAttachmentByUUID()` and immediately opens and copies the file to the response. There is no middleware or in-handler check that resolves the attachment's owning repository and verifies the caller's visibility. The UUID itself is a v4 random identifier, so the API surface is CWE-639 (authorization bypass through user-controlled key) combined with CWE-862 (missing authorization).
PR #8320 (commit `d3ca23f`) introduced the missing permission gate: the handler now resolves the repository linked to the attachment and enforces the same visibility checks applied to every other repository resource before serving the file.
The fix
Upgrade to Gogs 0.14.3 or later. The patch in PR #8320 adds repository-level permission checks to the attachment download handler, blocking access when the caller lacks view rights. As a temporary measure, set `REQUIRE_SIGNIN_VIEW = true` in `app.ini` and restrict the `/attachments/` path at a reverse proxy or WAF, though neither alone is a full fix because authenticated-but-unpermissioned users remain affected until the code-level check is in place.