A critical security vulnerability has been identified in Gogs, a widely used open-source self-hosted Git service. /
Tracked as CVE-2026-25921, this flaw allows unauthenticated attackers to silently overwrite Git Large File Storage (LFS) objects across any repository.
By exploiting a lack of content verification, threat actors can conduct stealthy software supply-chain attacks, replacing legitimate project files with malicious backdoors.
- CVE ID: CVE-2026-25921
- Severity: Critical (CVSS v3.1 Score: 9.3)
- Affected Software: gogs.io/gogs (Go ecosystem)
- Affected Versions: 0.14.1 and earlier
- Patched Versions: 0.14.2
- Weakness: CWE-345 (Insufficient Verification of Data Authenticity)
Technical Details of the Flaw
Git LFS is designed to replace large files, such as audio, datasets, and compiled binaries, with text pointers inside Git, storing the actual file contents on a remote server.
The vulnerability in Gogs stems from two dangerous architectural decisions in how these remote files are handled:
- Lack of Repository Isolation: Gogs stores all LFS objects in a single, global directory tree. The storage path is generated based solely on the Object ID (OID), without linking the file to a specific repository ID. This means objects are completely shared across the entire Gogs instance.
- Missing Content Verification: When a user uploads an LFS object, Gogs completely fails to verify that the actual uploaded file content matches its claimed SHA-256 hash, which is used as the OID. The application simply accepts the client’s file and saves it without validating its authenticity.
- Unsafe Overwrite Permissions: The server’s code explicitly allows clients to retry uploads and overwrite existing files, assuming that identical OIDs always mean identical content. This assumption breaks down entirely when a malicious client is involved.
An attacker can exploit this flaw with very low complexity over the network. The attack begins when a threat actor identifies the OID of a target LFS object in a victim’s repository.
The attacker then initiates a file upload to their own repository but intentionally uses the victim’s OID.
During this upload, the attacker submits a tampered file, such as a compromised binary or a script embedded with malware.
Gogs blindly accepts the file and overwrites the legitimate LFS object in the global storage path.
Because there is no integrity check, users downloading the target LFS object from the original repository will silently receive the attacker’s malicious payload.
There are no warnings presented on the webpage or the command line, making this an incredibly dangerous vector for software supply-chain compromises.
Following the disclosure of CVE-2026-25921 by security researcher zjuchenyuan, the maintainers of Gogs released an official fix.
Organizations relying on Gogs must implement the following defensive measures:
- Apply the Official Patch: Administrators should immediately update their Gogs instances to version 0.14.2 or later, which introduces mandatory verification to ensure uploaded LFS objects strictly match their claimed SHA-256 hashes.
- Verify LFS Integrity: After upgrading, security teams should manually verify the integrity of their existing LFS objects to ensure no files were maliciously overwritten prior to the patch.
- Monitor Access: If immediate patching is not possible, organizations should restrict network access to the Gogs instance or temporarily disable external user registrations to prevent unauthorized actors from creating repositories to host malicious uploads.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
