Listen to this Post
How CVE-2026-52799 Works
The vulnerability exists due to missing authorization in the attachment download endpoint when handling requests for attachment UUIDs. In Gogs 0.14.1, the `GET /attachments/:uuid` endpoint 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. The relevant code in `internal/cmd/web.go:306` shows a direct lookup and file serving mechanism with no permission validation:
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(<code>inline; filename="%s"</code>, 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. The relevant code in `internal/database/attachment.go:124` simply retrieves the attachment by UUID without any access control checks:
func GetAttachmentByUUID(uuid string) (Attachment, error) {
return getAttachmentByUUID(x, uuid)
}
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. In a test environment with REQUIRE_SIGNIN_VIEW = false, an unauthenticated user can download attachments belonging to a private repository. 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.
DailyCVE Form:
Platform: Gogs
Version: 0.14.1
Vulnerability: Missing Authorization
Severity: Medium (CVSS 4.0)
date: June 19, 2026
Prediction: Patch expected immediately
What Undercode Say:
Analytics:
The vulnerability allows a remote attacker to disclose sensitive information. Unauthenticated exploitation requires `REQUIRE_SIGNIN_VIEW` to be set to false. If sign-in is required, a logged-in user without access to the target repository may still retrieve the attachment. The attack vector is remote, requires low attack complexity, and no privileges. No public exploit is currently available.
Bash Commands and Codes:
To reproduce the vulnerability:
Create a private repository and add an attachment to an Issue Note the attachment UUID (example: f06d90f8-5b62-4c10-ac8d-f11fdf870b57) As an unauthenticated user, download the attachment directly curl -O http://gogs-instance/attachments/f06d90f8-5b62-4c10-ac8d-f11fdf870b57 The repository page returns 404 Not Found curl http://gogs-instance/myadmin/idor-attach-1770724346-1a13bb The Issue page also returns 404 Not Found curl http://gogs-instance/myadmin/idor-attach-1770724346-1a13bb/issues/1 But the attachment is successfully downloaded
Exploit:
A remote attacker can exploit this vulnerability by sending a request to the attachment download endpoint with a known attachment UUID. The steps are:
1. Identify a target Gogs instance (version 0.14.1).
- Obtain or guess a valid attachment UUID (e.g., through information disclosure, brute-force, or by observing attachment URLs in public contexts).
3. Send a GET request to `/attachments/`.
- The server returns the raw attachment file without any authorization checks.
The attacker does not need to authenticate ifREQUIRE_SIGNIN_VIEW = false. If authentication is required, the attacker only needs valid credentials, not repository access permissions.
Protection:
To mitigate this vulnerability, administrators should install the security update from the vendor’s website. The issue has been fixed in version 0.14.1. As a temporary workaround, administrators can restrict access to the `/attachments/` endpoint using a web application firewall (WAF) or reverse proxy rules, or ensure that `REQUIRE_SIGNIN_VIEW` is set to `true` and implement additional repository-level permission checks.
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.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
