CVE-2026-25921: 
Gogs vulnerability analysis and mitigation

CVE-2026-25921 is a cross-repository LFS (Large File Storage) object overwrite vulnerability in Gogs, an open-source self-hosted Git service, that enables supply-chain attacks by allowing any authenticated user to silently replace LFS objects belonging to other repositories. The vulnerability affects all Gogs versions up to and including 0.14.1, and was disclosed on March 5, 2026. It has been patched in version 0.14.2. The CVSS v3.1 base score is 9.3 (Critical) (Github Advisory, Gogs Advisory).

The vulnerability stems from two compounding design flaws classified under CWE-345 (Insufficient Verification of Data Authenticity). First, Gogs stores all LFS objects in a shared, flat directory structure (data/lfs-objects/<oid[0]>/<oid[1]>/<oid>) without any per-repository isolation — the repository ID is never incorporated into the storage path (internal/lfsutil/storage.go). Second, the upload handler (internal/route/lfs/basic.go) did not verify that the content of an uploaded file matched its claimed SHA-256 OID, and a code comment explicitly trusted clients to safely overwrite files on retry. This combination means any authenticated user with write access to any repository can issue a PUT request to the LFS upload endpoint of their own repository using a known OID from another repository, supplying arbitrary content that overwrites the shared on-disk object without any integrity check (Gogs Advisory, Fix PR).

Successful exploitation allows an attacker to silently replace any LFS object across all repositories hosted on the Gogs instance with arbitrary content, including malicious binaries or backdoored files. Because LFS objects are typically large binary assets (compiled executables, libraries, datasets), this creates a direct supply-chain attack vector: downstream users or CI/CD pipelines that pull from affected repositories will receive tampered files with no integrity warning. The scope is changed (S:C in CVSS), meaning the impact extends beyond the attacker's own repository to all repositories on the instance. Confidentiality is not directly impacted, but integrity is critically compromised and availability may be partially degraded (Github Advisory, GBHackers).

A detailed proof-of-concept exploit is publicly available in the official security advisory, providing concrete step-by-step HTTP requests with actual payloads demonstrating cross-repository LFS object overwrite (Gogs Advisory). The vulnerability requires only a valid Gogs account (any repository write access) and knowledge of a target OID — no elevated privileges are needed. There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.018% (0.000180), indicating a currently low probability of active exploitation. The vulnerability is not listed in the CISA KEV catalog. Qualys has added detection for this issue (detection ID 761789) (Feedly).

1. Reconnaissance: Identify a target Gogs instance running version 0.14.1 or earlier. Enumerate public repositories to find LFS-enabled repos and note the OIDs of LFS objects of interest (e.g., by browsing repository contents or using the LFS batch API).
2. Obtain a Gogs account: Register or use an existing account with write access to any repository on the target instance. No admin privileges are required.
3. Identify target OID: Obtain the SHA-256 OID of the LFS object to be overwritten from the victim repository (e.g., 5f8c5042d51400e9e2e9bed01353edacf72edc88340038145229cd494b5fe08a).
4. Initiate LFS batch upload: Send a POST request to the attacker-controlled repository's LFS batch endpoint to obtain an upload URL for the target OID:

   POST http://<host>/<attacker_user>/<attacker_repo>.git/info/lfs/objects/batch
   Authorization: Basic <attacker_credentials>
   Content-Type: application/vnd.git-lfs+json
   {"operation": "upload", "objects": [{"oid": "<target_oid>", "size": <size>}], "ref": {"name": "refs/heads/master"}}

5. Upload malicious content: Issue a PUT request to the LFS upload endpoint using the target OID path, supplying arbitrary malicious content (e.g., a backdoored binary). Because the server does not verify content against the OID hash and uses a shared storage path, this overwrites the victim repository's LFS object:

   PUT http://<host>/<attacker_user>/<attacker_repo>.git/info/lfs/objects/basic/<target_oid>
   Authorization: Basic <attacker_credentials>
   Content-Type: application/octet-stream
   <malicious_payload>

6. Verify overwrite: Confirm the victim repository now serves the malicious content by downloading the LFS object from the victim repository's endpoint. Any user or pipeline pulling this LFS object will now receive the attacker's payload with no integrity warning (Gogs Advisory).

• Network: Unexpected PUT requests to /<repo>/info/lfs/objects/basic/<oid> from a user account that does not own the repository associated with that OID; LFS upload requests where the uploading user's repository differs from the repository whose OID is being targeted.
• Logs: Gogs access logs showing PUT requests to LFS upload endpoints (/info/lfs/objects/basic/<oid>) from accounts other than the repository owner, especially across different repository namespaces; repeated LFS uploads of the same OID from different user accounts.
• File System: Unexpected modification timestamps on files under the LFS objects storage directory (data/lfs-objects/); LFS object files whose SHA-256 hash does not match their filename (OID); presence of unexpected binary content in LFS object files.
• Behavioral: Users or CI/CD pipelines reporting unexpected or corrupted LFS file content after a git lfs pull; checksum mismatches when manually verifying LFS objects against their OIDs (Gogs Advisory).

Upgrade Gogs to version 0.14.2 or later immediately, as this release introduces SHA-256 content verification during LFS upload and uses atomic file creation (O_CREATE|O_EXCL) to prevent overwriting existing LFS objects (Gogs Release, Fix PR). Note that version 0.14.3 is also available and recommended by the Gogs maintainers. There is no known configuration-based workaround for unpatched versions; the only effective remediation is upgrading. After upgrading, administrators should audit existing LFS objects by verifying each file's SHA-256 hash against its OID filename to detect any prior tampering, and review access logs for suspicious cross-repository LFS upload activity.

The vulnerability received broad coverage from security news outlets including SecurityOnline, GBHackers, CyberSecurityNews, and CyberPress, with articles highlighting the supply-chain attack potential (SecurityOnline, GBHackers). The Hacker News weekly recap also included mention of the vulnerability. Social media discussion on Mastodon and InfoSec.Exchange noted the severity and supply-chain implications. The Hacker Wire published a dedicated technical analysis (The Hacker Wire). Red Hat also tracked the CVE for potential impact on their products (Red Hat).