CVE-2026-52812 is a high-severity missing authorization vulnerability in gogs.io/gogs (go), affecting versions < 0.14.3. It is fixed in 0.14.3.
Summary Git LFS storage is content-addressed by OID alone (<LFS-root>/<oid[0]>/<oid[1]>/<oid>) but per-repo authorization lives in the lfsobject table keyed (repoid, oid). serveUpload skips re-uploading when the OID file already exists on disk and inserts a new (repoid, oid) row pointing at it without verifying the request body hashes to the OID being claimed. Any user with write access to one repo can bind their repo to an OID owned by a private repo and download the original bytes via their own download endpoint. Details Dedupe shortcut at internal/lfsx/storage.go:79-82: Hash verification at internal/lfsx/storage.go:106-108 only runs in the new-file branch, the dedupe path returns earlier. serveUpload (internal/route/lfs/basic.go:78-114) trusts that success and inserts the per-repo binding: CreateLFSObject is an unconditional INSERT on (repoid, oid) with no check that the OID is referenced by the requesting repo's git history. serveDownload at internal/route/lfs/basic.go:42-72 only consults the per-repo row, then streams from the shared content-addressed file. Suggested fix In LocalStorage.Upload, when os.Stat(fpath) == nil, hash the request body via io.TeeReader and ErrOIDMismatch on disagreement, same code path as the new-file branch already uses. The "client retries after partial failure" use case still works; the retry just has to send the correct content. Optional second layer: in serveUpload, refuse CreateLFSObject unless the OID is referenced by an LFS pointer in the requesting repo's refs. PoC Tested against gogs at HEAD d7571322 (also reproduces on v0.14.2, paths are internal/lfsutil/storage.go and identical logic). Reproduction prerequisites Running gogs ≥ 0.12.0 with [lfs] ENABLED = true. Two accounts: alice (private repo secrets) and bob (any repo bob/scratch); bob has no access to alice/secrets. An OID known to be present in alice/secrets, leaked LFS pointer file in any public ancestor commit, stale fork, support ticket, or any side channel. Brute force is infeasible (256-bit). Setup (testbed simulation of the victim's prior state) Attack, bob has only $OID, not $VICTIM_BYTES Independent confirmation against the source Impact Cross-tenant disclosure of any LFS object on the instance. Attacker needs HTTP write to one repo + knowledge of a target OID; storage path is global, no per-repo isolation. LFS commonly stores certificates/keys, firmware blobs, ML model weights, datasets containing PII, packaged installers, all extracted byte-for-byte. Persistent: the (bob/scratch, OID) row pins read access until manually deleted; removing bob's repo write access does not revoke prior binds. No artefact on victim's side beyond a 200 in the LFS access log.
The application does not perform an authorization check before performing a sensitive operation. Typical impact: unauthorized access to restricted functionality or data.
go
gogs.io/gogs (< 0.14.3)gogs.io/gogs → 0.14.3 (go)Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter instead of chasing every advisory.
Kodem's runtime-powered SCA identifies whether CVE-2026-52812 is reachable in your applications. Explore open-source security for your team.
See if CVE-2026-52812 is reachable in your applications. Get a demo
Already deployed Kodem? See CVE-2026-52812 in your environment →Upgrade gogs.io/gogs to 0.14.3 or later to resolve this vulnerability.
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
CVE-2026-52812 is a high-severity missing authorization vulnerability in gogs.io/gogs (go), affecting versions < 0.14.3. It is fixed in 0.14.3. The application does not perform an authorization check before performing a sensitive operation.
gogs.io/gogs (go) versions < 0.14.3 is affected.
Yes. CVE-2026-52812 is fixed in 0.14.3. Upgrade to this version or later.
Whether CVE-2026-52812 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
Upgrade gogs.io/gogs to 0.14.3 or later.