CVE-2026-20897: Gitea Auth Bypass Vulnerability

CVE-2026-20897 Overview

CVE-2026-20897 is an authorization bypass vulnerability in Gitea that allows improper validation of repository ownership when deleting Git LFS (Large File Storage) locks. A user with write access to one repository may exploit this flaw to delete LFS locks belonging to other repositories, potentially disrupting collaborative workflows and version control integrity.

Critical Impact

This vulnerability enables cross-repository manipulation of Git LFS locks, which could allow malicious actors with limited repository access to interfere with file locking mechanisms in repositories they should not have control over, potentially causing data conflicts and workflow disruptions.

Affected Products

• Gitea versions prior to 1.25.4

Discovery Timeline

• 2026-01-22 - CVE CVE-2026-20897 published to NVD
• 2026-01-22 - Last updated in NVD database

Technical Details for CVE-2026-20897

Vulnerability Analysis

This vulnerability is classified under CWE-284 (Improper Access Control). The issue arises from insufficient validation in Gitea's Git LFS lock deletion functionality. When a user attempts to delete an LFS lock, the application fails to properly verify that the lock belongs to a repository the user has authorization to manage. This allows users with write access to one repository to manipulate LFS locks in other repositories.

Git LFS locks are a critical feature for preventing merge conflicts when multiple collaborators work on large binary files. The lock mechanism ensures exclusive access to files during editing. By bypassing the ownership validation, an attacker could unlock files in repositories they shouldn't have access to, potentially causing concurrent edits, data corruption, or workflow disruptions.

Root Cause

The root cause of this vulnerability is improper access control in the repository ownership validation logic during Git LFS lock deletion operations. The application does not adequately verify that the repository associated with the LFS lock matches the repository the authenticated user has write permissions for. This missing authorization check creates a horizontal privilege escalation condition where users can affect resources outside their intended scope.

Attack Vector

An attacker with write access to at least one repository on a Gitea instance can exploit this vulnerability by sending crafted requests to delete LFS locks. By manipulating the lock identifiers or repository references in the deletion request, the attacker can target LFS locks in repositories they do not have proper authorization for.

The attack requires authenticated access with write permissions to at least one repository. The attacker would need to discover or enumerate lock IDs from target repositories, then submit deletion requests referencing those locks. The lack of proper repository ownership validation allows these cross-repository operations to succeed.

For technical details on the vulnerability and fix implementation, refer to the GitHub Security Advisory GHSA-rrq5-r9h5-pc7c and related pull requests #36344 and #36349.

Detection Methods for CVE-2026-20897

Indicators of Compromise

• Unexpected deletion of Git LFS locks across repositories
• Audit log entries showing LFS lock deletions by users without appropriate repository access
• User complaints about LFS locks being removed without authorization
• Anomalous cross-repository API activity related to LFS operations

Detection Strategies

• Review Gitea access logs for LFS lock deletion requests and cross-reference with user repository permissions
• Implement audit logging for all LFS lock operations to track lock creation and deletion events
• Monitor for patterns of LFS lock deletions across multiple repositories by a single user account
• Set up alerts for unusual API activity targeting LFS endpoints

Monitoring Recommendations

• Enable verbose logging for Git LFS operations in Gitea configuration
• Implement real-time monitoring of LFS lock deletion events with user context
• Regularly audit user permissions and repository access patterns
• Configure alerting for LFS lock manipulation activity outside normal working patterns

How to Mitigate CVE-2026-20897

Immediate Actions Required

• Upgrade Gitea to version 1.25.4 or later immediately
• Audit recent LFS lock deletion activities to identify potential exploitation
• Review repository access permissions and ensure principle of least privilege
• Consider temporarily restricting LFS lock deletion capabilities until the patch is applied

Patch Information

Gitea has released version 1.25.4 which addresses this vulnerability. The fix adds proper repository ownership validation before allowing LFS lock deletion operations. Organizations running affected versions should upgrade as soon as possible.

Detailed patch information is available at the Gitea Release v1.25.4 page and the Gitea Blog Release Announcement.

Workarounds

• Restrict Git LFS functionality at the server level until the patch can be applied
• Implement network-level access controls to limit API access to trusted users
• Use repository-level webhooks to monitor and alert on LFS lock changes
• Consider using external LFS storage services with independent access controls as a temporary measure

# Upgrade Gitea to patched version
# Stop the Gitea service
sudo systemctl stop gitea

# Download the latest patched release (1.25.4 or later)
wget https://github.com/go-gitea/gitea/releases/download/v1.25.4/gitea-1.25.4-linux-amd64

# Replace the binary and set permissions
sudo cp gitea-1.25.4-linux-amd64 /usr/local/bin/gitea
sudo chmod +x /usr/local/bin/gitea

# Restart the service
sudo systemctl start gitea