Skip to main content

Gogs EUVDEUVD-2026-39071

| CVE-2026-52799 HIGH
Authorization Bypass Through User-Controlled Key (CWE-639)
2026-06-22 https://github.com/gogs/gogs GHSA-p9f5-h3rx-j5qw
7.5
CVSS 3.1 · Vendor: https://github.com/gogs/gogs
Share

Severity by source

Vendor (https://github.com/gogs/gogs) PRIMARY
7.5 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
vuln.today AI
7.5 HIGH

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.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
SUSE
HIGH
qualitative

Primary rating from Vendor (https://github.com/gogs/gogs).

CVSS VectorVendor: https://github.com/gogs/gogs

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
None
Availability
None

Lifecycle Timeline

2
Source Code Evidence Fetched
Jun 23, 2026 - 00:14 vuln.today
Analysis Generated
Jun 23, 2026 - 00:14 vuln.today

DescriptionCVE.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):

go
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):

go
// 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

  1. Log in as an administrator and create a private repository, e.g. myadmin/idor-attach-1770724346-1a13bb.
  2. Add an attachment to an Issue in that repository and note the attachment UUID

(example UUID used during testing: f06d90f8-5b62-4c10-ac8d-f11fdf870b57).

  1. 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.

Vendor 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

Share

EUVD-2026-39071 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy