CVE-2026-25921: Gogs LFS Supply-Chain Attack Vulnerability

CVE-2026-25921 Overview

CVE-2026-25921 is a critical vulnerability affecting Gogs, an open source self-hosted Git service. Prior to version 0.14.2, the application contains an overwritable LFS (Large File Storage) object vulnerability that allows malicious actors to overwrite LFS objects across different repositories. This flaw enables supply-chain attacks where attackers can replace legitimate files with malicious content, potentially compromising downstream users and systems that depend on the affected repositories.

Critical Impact
This vulnerability allows unauthenticated attackers to overwrite any LFS object across repositories, enabling supply-chain attacks that could compromise software integrity and affect all users consuming files from affected Gogs instances.

Affected Products

Gogs versions prior to 0.14.2
All Gogs installations with LFS enabled
Repositories utilizing Git LFS for large file storage

Discovery Timeline

March 5, 2026 - CVE-2026-25921 published to NVD
March 5, 2026 - Last updated in NVD database

Technical Details for CVE-2026-25921

Vulnerability Analysis

This vulnerability is classified under CWE-345 (Insufficient Verification of Data Authenticity), indicating that the Gogs application fails to properly verify the authenticity and ownership of LFS objects before allowing modifications. The attack can be executed remotely over the network without requiring authentication or user interaction. The vulnerability has a changed scope, meaning successful exploitation can impact resources beyond the vulnerable component itself, specifically affecting downstream consumers of the compromised LFS objects.

The integrity impact is significant as attackers can modify LFS objects that other repositories and users depend on, while availability is partially affected due to potential disruption of legitimate file access.

Root Cause

The root cause lies in the insufficient access control validation within Gogs' LFS implementation. The application does not properly verify repository ownership or permissions when processing LFS object uploads, allowing objects with the same content hash to be overwritten regardless of which repository originally created them. This architectural flaw in the LFS object storage mechanism fails to implement proper isolation between repositories.

Attack Vector

The attack exploits the shared LFS object storage architecture in Gogs. Since LFS objects are typically stored based on their content hash (SHA-256), and Gogs did not properly enforce repository-level access controls on these objects, an attacker can:

Identify the hash of a target LFS object in a victim repository
Create a malicious file with the same hash or upload a replacement object
Overwrite the legitimate LFS object with malicious content
All repositories referencing that LFS object will now serve the malicious content

This creates a severe supply-chain risk where software dependencies, binaries, or other critical files stored in LFS can be silently replaced with backdoored or malicious versions.

For detailed technical analysis, refer to the GitHub Security Advisory GHSA-cj4v-437j-jq4c and the associated pull request.

Detection Methods for CVE-2026-25921

Indicators of Compromise

Unexpected modifications to LFS object timestamps or metadata
Hash mismatches between expected and actual LFS object content
Anomalous LFS upload activity from unrecognized sources or repositories
User reports of corrupted or unexpected file content from LFS-tracked files

Detection Strategies

Monitor LFS object access logs for cross-repository write operations
Implement integrity verification by comparing LFS object hashes against known-good values
Deploy file integrity monitoring on the LFS storage backend directory
Review Git audit logs for suspicious repository activity patterns

Monitoring Recommendations

Enable comprehensive logging for all LFS API endpoints
Set up alerts for LFS object modifications outside of normal CI/CD workflows
Implement content verification pipelines for critical LFS-stored artifacts
Regularly audit LFS object ownership and access patterns

How to Mitigate CVE-2026-25921

Immediate Actions Required

Upgrade Gogs to version 0.14.2 or later immediately
Audit all LFS objects for potential unauthorized modifications
Verify integrity of critical files stored in LFS against known-good backups
Review access logs for any suspicious LFS-related activity prior to patching

Patch Information

Gogs has released version 0.14.2 which addresses this vulnerability by implementing proper repository-level access controls for LFS objects. The fix ensures that LFS objects can only be modified by users with appropriate permissions on the owning repository.

Patched Version:0.14.2
Security Commit:81ee8836445ac888d99da8b652be7d5cbc5c4d5c
Release Notes:Gogs v0.14.2
Security Advisory:GHSA-cj4v-437j-jq4c

Workarounds

Temporarily disable LFS functionality if immediate patching is not possible
Implement network-level access controls to restrict LFS endpoint access to trusted sources
Deploy a reverse proxy with additional authentication requirements for LFS operations
Consider migrating critical LFS objects to an alternative secure storage solution until patching is complete

bash

# Check current Gogs version
gogs --version

# Backup existing data before upgrade
tar -czvf gogs-backup-$(date +%Y%m%d).tar.gz /path/to/gogs-repositories

# Upgrade to patched version 0.14.2
# Follow official Gogs upgrade documentation for your installation method