Skip to content

Attachments created before the January 2026 cutoff skip the cross repository check entirely, and permission is then evaluated against the repository named in the URL rather than the repository owning the attachment, so a private repository's attachment is served through any public repository's path

Moderate
bircni published GHSA-frpv-2xgv-wxpq Aug 29, 2026

Package

gomod gitea.dev (Go)

Affected versions

>= 1.26.0, <= 1.27.2

Patched versions

1.27.3

Description

Summary

The web attachment handler contains a guard that rejects a request for an attachment made through a repository other than the one that owns it. That guard is applied only to attachments created after 16 January 2026; older attachments skip it even when their owning-repository id is correctly populated. When the guard is skipped, the handler evaluates permission against the repository named in the request URL instead of the repository that owns the attachment. An attachment belonging to a private repository can therefore be retrieved by requesting it through any public repository's attachment path. The route allows anonymous access, so no authentication is required.

Details

In routers/web/repo/attachment.go the cross-repository check is gated only on the attachment's creation timestamp, unlike its two sibling call sites which also require the owning-repository id to be unset. A migration backfills that id on upgrade, so the timestamp-only exemption protects no legitimate rows and instead allows permission to be checked against the wrong repository. Downstream draft-release and token-scope checks inherit the same wrong subject. Attachment UUIDs are random and not enumerable, so exploitation requires knowledge of a specific attachment UUID (for example from a removed collaborator, a public-to-private conversion, notification mail, webhook payloads, or proxy/CDN logs).

Impact

Disclosure of private-repository attachment contents — issue and pull request attachments and release assets — to an unauthenticated caller who knows the attachment UUID. Incorrect authorization / cross-repository access control bypass. Affects any instance that held attachments created before 16 January 2026.

Affected versions

Gitea >= 1.26.0, <= 1.27.2.

Patches

Fixed in Gitea 1.27.3 (#39048, #39077).

Workarounds

None. Upgrade to 1.27.3.

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
High
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
None
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

CVE ID

CVE-2026-78433

Weaknesses

Improper Access Control

The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor. Learn more on MITRE.

Authorization Bypass Through User-Controlled Key

The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data. Learn more on MITRE.

Incorrect Authorization

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. Learn more on MITRE.

Insufficient Granularity of Access Control

The product implements access controls via a policy or other feature with the intention to disable or restrict accesses (reads and/or writes) to assets in a system from untrusted agents. However, implemented access controls lack required granularity, which renders the control policy too broad because it allows accesses from unauthorized agents to the security-sensitive assets. Learn more on MITRE.

Credits