Gogs stores Git Large File Storage objects by their OID alone and does not associate the file path with the owning repository. When a file with the same OID already exists on disk, the upload logic creates a new (repo_id, oid) mapping without verifying that the uploaded data matches the claimed OID. Any user who has write access to a repository can therefore bind that repository to another repository’s private LFS object and download the original private content through their own download endpoint. This results in an information disclosure as described by CWE‑345, enabled by improper privilege checks (CWE‑639) and missing authorization controls (CWE‑862).

Affected vendor: Gogs, product: self‑hosted Git service. The vulnerability exists in all releases prior to 0.14.3; a fixed version is available as v0.14.3 and later.

The CVSS score of 7.1 indicates high severity. EPSS is not available, and the issue is not listed in the CISA KEV catalog. Based on the description, it is inferred that the attack vector is remote via the Gogs web interface, requiring the attacker to possess write permissions on a repository within the same instance. No elevated system privileges are needed. Once the attacker binds a private LFS OID to their own repo, they can retrieve the private content, leading to a confidentiality compromise for multi‑tenant or shared deployments.