Gogs Vulnerability Lets Attackers Quietly Overwrite Big File Storage Objects

Gogs Vulnerability Overwrites Large File Storage Objects A serious security hole has been found in a well-known open-source Git service that people host themselves. This hole lets attackers secretly overwrite Large File Storage (LFS) objects. This vulnerability, which has a CVSS 3.1 score of 10.0, is the most serious one tracked as CVE-2026-25921.

It makes software supply-chain attacks much more likely. The bug only affects Gogs versions 0.14.1 and earlier, and at the time of the disclosure, there was no official patch available. If exploited, bad actors could change important binaries, datasets, or software builds in any repository on a shared server without getting a single warning.

Gogs Overwrite Security Flaw This vulnerability is caused by two major design flaws in how Gogs handles its Large File Storage architecture: Not enough storage Isolation: Gogs keeps all uploaded LFS objects in one place that everyone can access, without separating them by repository. Since the storage path doesn't have a unique repository ID, all the projects on the Gogs instance use the same centralized file pool. When a user uploads an LFS file, Gogs doesn't check to see if the file's actual content matches its claimed SHA-256 cryptographic hash (also known as the OID).

An attacker only needs to know the SHA-256 hash of a target LFS file because these security checks are missing.

The attacker can then upload a modified file, like a backdoored software installer, to their own repository while pretending to be the victim's file hash. The Gogs server thinks that the upload is just a normal client retry and overwrites the original, valid file in the shared storage database without thinking. The impact of CVE-2026-25921 is devastating because it requires low attack complexity, no special privileges, and zero user interaction.

Supply-Chain Compromise: If real developers or automated systems download LFS objects from the affected server, they will unknowingly get the attacker's backdoored file. Undetectable Tampering: The system trusts the attacker's altered file without checking its data authenticity (CWE-345), so the overwrite happens without anyone knowing.

When victims download the LFS object from the Gogs website, there will be no warnings, errors, or alerts that the file has been changed. Security researcher zjuchenyuan found the flaw and told others about it. Organizations that use self-hosted Gogs instances need to be very careful because there isn't an official patched version yet.

Until an official fix is released, administrators should think about the following temporary security steps: Limit Permissions: To stop people who shouldn't have access from overwriting files, only allow highly trusted internal users to create accounts and upload LFS files. Manual Integrity Checks: Use external monitoring scripts to check on a regular basis that the actual SHA-256 hashes of important LFS files on the host disk are the same as what the database says they should be.

The final developer fix will require Gogs to make sure that all uploaded LFS objects mathematically match their claimed SHA-256 hash before writing them to the server disk. Follow LinkedIn and X for daily cybersecurity updates. Get in touch with us to tell your stories.