CVE-2026-52812: Gogs Git LFS Auth Bypass Vulnerability

CVE-2026-52812 Overview

CVE-2026-52812 is an insufficient verification of data authenticity flaw [CWE-345] in Gogs, an open source self-hosted Git service. Versions prior to 0.14.3 deduplicate Git Large File Storage (LFS) objects by Object ID (OID) without validating that an uploader actually possesses the underlying bytes. Any authenticated user with write access to one repository can register an OID owned by a private repository against their own repository and retrieve the original content through the standard download endpoint. The vulnerability is fixed in Gogs 0.14.3.

Critical Impact
Authenticated low-privileged users can exfiltrate Git LFS blobs from private repositories by referencing known OIDs, defeating repository-level access controls.

Affected Products

Gogs versions prior to 0.14.3
Self-hosted Gogs instances with Git LFS enabled
Multi-tenant Gogs deployments hosting both public and private repositories

Discovery Timeline

2026-06-24 - CVE-2026-52812 published to NVD
2026-06-25 - Last updated in NVD database

Technical Details for CVE-2026-52812

Vulnerability Analysis

Gogs stores Git LFS objects on disk in a content-addressed layout of <LFS-root>/<oid[0]>/<oid[1]>/<oid>, where the OID is the SHA-256 hash of the object content. Per-repository authorization is enforced separately through the lfs_object database table, keyed on (repo_id, oid). The serveUpload handler in internal/lfsx/storage.go treated the presence of an object on disk as proof that the upload was complete and discarded the request body without inspection.

When the file already existed, the server inserted a new (repo_id, oid) row binding the caller's repository to the existing object, then returned success. Because the body was never hashed, the uploader did not need to know or transmit the actual bytes. An attacker only needed the OID, which can leak through commit metadata, error messages, mirrored manifests, or backup artifacts.

After the fraudulent binding, the attacker's own repository LFS download endpoint serves the original bytes belonging to the private repository, bypassing the per-repository access check entirely.

Root Cause

The deduplication shortcut conflated storage presence with proof of possession. The server never executed the cryptographic check that gives content-addressed storage its security property, namely confirming that SHA-256(request_body) == oid. This is a classic Insufficient Verification of Data Authenticity [CWE-345] failure.

Attack Vector

Exploitation requires only network access and a low-privileged authenticated account with write access to any single repository on the target Gogs instance. No user interaction is needed. The attack proceeds as follows: obtain the target OID, initiate an LFS upload to a repository the attacker controls, claim the target OID with an arbitrary body, and then download the object via the attacker's repository.

// Patch from internal/lfsx/storage.go - verify content hash on LFS dedupe shortcut (#8333)
// Source: https://github.com/gogs/gogs/commit/f35a767af74e05342bafc6fdda02c791816426f8

//	return 0, errors.Wrap(err, "create directories")
// }

// Before: existing-file shortcut discarded the body without verification.
// After: the client must still prove it has the original bytes by
// hashing the request body. Otherwise any caller with write access to
// one repository could bind an OID owned by another repository to their
// own and download the original content.
if fi, err := os.Stat(fpath); err == nil {
    hash := sha256.New()
    if _, err := io.Copy(hash, rc); err != nil {
        return 0, errors.Wrap(err, "read request body")
    }
    if computed := hex.EncodeToString(hash.Sum(nil)); computed != string(oid) {
        return 0, ErrOIDMismatch
    }
    return fi.Size(), nil
}

Detection Methods for CVE-2026-52812

Indicators of Compromise

Rows in the lfs_object table where the same oid is associated with multiple repo_id values across users who do not share collaboration relationships.
LFS upload requests that complete with HTTP 200 in unusually short time, indicating the dedupe shortcut path was taken.
LFS download requests for OIDs that were never pushed as part of an actual Git commit in the requesting repository.

Detection Strategies

Audit the lfs_object table for OIDs that appear in both private and public or low-trust repositories, then cross-reference against repository commit histories to identify bindings unsupported by Git history.
Inspect Gogs application logs and reverse-proxy access logs for PUT requests to LFS upload URLs followed by GET requests for the same OID from the same actor within a short window.
Correlate authenticated user activity against repository visibility transitions to flag accounts that touched OIDs belonging to private repositories.

Monitoring Recommendations

Enable verbose request logging for the LFS upload and download handlers and forward to a centralized log platform for retention and search.
Alert on first-time (user, oid) pairs where the user has no prior commit referencing that OID in any accessible repository.
Track instance version metadata and trigger alerts when a Gogs deployment reports a version below 0.14.3.

How to Mitigate CVE-2026-52812

Immediate Actions Required

Upgrade all Gogs instances to version 0.14.3 or later, which adds SHA-256 verification on the LFS deduplication path.
Rotate any secrets, tokens, or credentials that may have been stored in LFS-tracked files within private repositories on affected instances.
Audit the lfs_object table to identify and remove cross-repository OID bindings that cannot be justified by Git history.

Patch Information

The fix is delivered in Gogs release v0.14.3 via pull request #8333 and commit f35a767. The patch requires the server to hash the request body and reject the upload with ErrOIDMismatch when the computed digest does not match the claimed OID. Full advisory details are available in GHSA-6p9m-q3jp-47h4.

Workarounds

Disable Git LFS on the Gogs instance until the upgrade can be applied if LFS is not actively required.
Restrict repository creation and write access to trusted users only, reducing the population of accounts capable of triggering the fraudulent binding.
Place the Gogs LFS endpoints behind an authenticated proxy that enforces stricter per-user upload quotas and logs full request metadata for forensic review.

bash

# Verify the running Gogs version and upgrade if below 0.14.3
gogs --version

# Example upgrade for binary installs
systemctl stop gogs
wget https://github.com/gogs/gogs/releases/download/v0.14.3/gogs_0.14.3_linux_amd64.tar.gz
tar -xzf gogs_0.14.3_linux_amd64.tar.gz -C /opt/
systemctl start gogs

# Optional: temporarily disable LFS in app.ini until patched
# [lfs]
# ENABLED = false