Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Remote unauthenticated HTTP GET against default config; confidentiality-only disclosure of private attachments, no integrity or availability impact; AC:L because the request is trivial once a UUID is known.
Primary rating from Vendor (https://github.com/gogs/gogs).
CVSS VectorVendor: https://github.com/gogs/gogs
Lifecycle Timeline
2DescriptionCVE.org
Summary
In Gogs 0.14.1, GET /attachments/:uuid returns the raw attachment file without verifying whether the requester has view permission for the associated Issue/Comment/Release or the repository. In a test environment with REQUIRE_SIGNIN_VIEW = false, we confirmed that an unauthenticated user can download attachments belonging to a private repository.
Description
/attachments/:uuid retrieves an attachment record solely by the UUID provided in the URL and returns the corresponding local file without performing any authorization checks against the attachment’s parent object (Issue/Comment/Release) or the repository it belongs to. As a result, even attachments under private repositories can be downloaded by an unauthenticated user (or a user without proper permissions) as long as the UUID is known.
Relevant code (internal/cmd/web.go:306):
m.Get("/attachments/:uuid", func(c *context.Context) {
attach, err := database.GetAttachmentByUUID(c.Params(":uuid"))
if err != nil {
c.NotFoundOrError(err, "get attachment by UUID")
return
} else if !com.IsFile(attach.LocalPath()) {
c.NotFound()
return
}
fr, err := os.Open(attach.LocalPath())
if err != nil {
c.Error(err, "open attachment file")
return
}
defer fr.Close()
c.Header().Set("Content-Security-Policy", "default-src 'none'; style-src 'unsafe-inline'; sandbox")
c.Header().Set("Cache-Control", "public,max-age=86400")
c.Header().Set("Content-Disposition", fmt.Sprintf(`inline; filename="%s"`, attach.Name))
if _, err = io.Copy(c.Resp, fr); err != nil {
c.Error(err, "copy from file to response")
return
}
})The UUID lookup itself also performs no validation tied to repository visibility or user permissions. Authorization is not enforced at this layer.
Relevant code (internal/database/attachment.go:124):
// GetAttachmentByUUID returns attachment by given UUID.
func GetAttachmentByUUID(uuid string) (*Attachment, error) {
return getAttachmentByUUID(x, uuid)
}Preconditions
- The attacker knows the target attachment’s UUID (i.e., the attachment URL).
- For unauthenticated exploitation:
[auth] REQUIRE_SIGNIN_VIEW = false. - Even when
REQUIRE_SIGNIN_VIEW = true, exploitation may still be possible because the handler does not check repository-level permissions; a user who can log in but lacks access to the target repository may still retrieve the attachment.
Steps to Reproduce
- Log in as an administrator and create a private repository, e.g.
myadmin/idor-attach-1770724346-1a13bb. - Add an attachment to an Issue in that repository and note the attachment UUID
(example UUID used during testing: f06d90f8-5b62-4c10-ac8d-f11fdf870b57).
- Log out and access the following as an unauthenticated user:
- The repository page → 404 Not Found
<img width="1702" height="758" alt="image" src="https://github.com/user-attachments/assets/8fdb1d92-cfc3-4ef8-977e-60ec13f792df" />
- The Issue page under that repository → 404 Not Found
<img width="1983" height="546" alt="image" src="https://github.com/user-attachments/assets/c44c5e69-8ca2-4ea6-a071-62302b7e896f" />
GET /attachments/<uuid>→ the attachment file is successfully downloaded
<img width="2007" height="378" alt="image" src="https://github.com/user-attachments/assets/23950ac6-6b3a-42f8-a06b-b9e0cf508d24" />
Minimum Required Privileges
REQUIRE_SIGNIN_VIEW = false: none (works without authentication).REQUIRE_SIGNIN_VIEW = true: only the ability to log in (repository view permission is not required in practice).
Impact
- Confidential information attached to private repositories or restricted Issues/Releases may be disclosed.
- Examples include credentials, cryptographic keys, personal data, internal documents, or unpublished source code fragments.
- While the severity depends on the attachment contents, attachments frequently contain sensitive data, making the potential impact high.
AnalysisAI
Information disclosure in Gogs 0.14.1 (and all versions ≤ 0.14.2) allows unauthenticated remote attackers who know or guess an attachment UUID to download files attached to issues, comments, and releases in private repositories. The /attachments/:uuid endpoint performs no repository-level authorization check, so private-repo attachments - credentials, keys, internal documents, unpublished source - leak when REQUIRE_SIGNIN_VIEW = false. No public exploit identified at time of analysis, but the GitHub Security Advisory GHSA-p9f5-h3rx-j5qw includes a full proof-of-concept reproduction.
Technical ContextAI
Gogs is a self-hosted Go-based Git service (pkg:go/gogs.io_gogs) competing with Gitea/GitLab/Forgejo. The vulnerable handler is registered in internal/cmd/web.go:306 and resolves attachments via database.GetAttachmentByUUID() (internal/database/attachment.go:124), which is a pure primary-key lookup with no join or filter on the parent Issue/Comment/Release or its owning repository's visibility flag. This is the textbook CWE-639 (Authorization Bypass Through User-Controlled Key / IDOR) pattern: the application trusts the UUID as both an identifier AND an implicit access token, conflating unguessability with authorization. The upstream fix in PR #8320 resolves the parent object (attach.IssueID or attach.ReleaseID), walks to its Repository, and enforces repo.HasAccess(c.UserID()) before serving the file, also tightening the response from Cache-Control: public to private.
RemediationAI
Vendor-released patch: upgrade to Gogs 0.14.3 or later (https://github.com/gogs/gogs/releases/tag/v0.14.3), which lands PR #8320 (https://github.com/gogs/gogs/pull/8320, commit d3ca23f9f33d5710472a775d6dcd3a7bb128bb05) and adds the missing repo.HasAccess() check on /attachments/:uuid. If immediate upgrade is impossible, set [auth] REQUIRE_SIGNIN_VIEW = true in app.ini to block unauthenticated download - note this only partially mitigates, since any logged-in user (including self-registered accounts) can still fetch attachments they should not see, so also disable open registration ([service] DISABLE_REGISTRATION = true) and consider a reverse-proxy rule blocking external requests to /attachments/ until patched. Audit access/proxy logs for prior /attachments/<uuid> hits from unexpected IPs and rotate any secrets that were stored as private-repo attachments.
Same technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: Important| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-39071
GHSA-p9f5-h3rx-j5qw