CVE-2026-20897: 
Gitea vulnerability analysis and mitigation

CVE-2026-20897 is an authorization bypass vulnerability in Gitea that allows a user with write access to one repository to delete Git LFS (Large File Storage) locks belonging to other repositories. It affects all Gitea versions prior to 1.25.4 and was published on January 22, 2026, with a patch released the same day. The GitHub Advisory Database (GHSA-393c-qgvj-3xph) assigns a CVSS v4 base score of 5.3 (Moderate), while the Feedly threat intelligence data records a CVSS v3.1 base score of 9.1 (Critical) — practitioners should note the discrepancy and consult the official advisory for authoritative scoring (GitHub Advisory, Gitea Release).

The root cause is improper access control (CWE-284) combined with authorization bypass through user-controlled key (CWE-639): when processing Git LFS lock deletion requests, Gitea failed to validate that the lock ID supplied by the requester actually belonged to the repository context of the authenticated user's request. This means an attacker can supply a lock ID from a different repository and the server will process the deletion without verifying ownership. The fix, implemented in pull requests #36344 and #36349 by contributor lunny, enforces that LFS locks must belong to the intended repository before any deletion is permitted (GitHub PR #36344, GitHub PR #36349, GitHub Advisory).

An authenticated user with write access to any repository on a Gitea instance can delete Git LFS locks from repositories they do not own or have access to. This disrupts collaborative workflows that rely on LFS locks to prevent concurrent modifications to large binary files, potentially enabling multiple users to modify the same files simultaneously and causing data conflicts or corruption. The integrity impact is significant in multi-team or multi-project environments, though there is no direct code execution or confidentiality exposure (GitHub Advisory, Feedly).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the time of disclosure (GitHub Advisory). The EPSS score is approximately 0.017–0.021%, placing it in the 6th percentile for exploitation likelihood within 30 days. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires a valid Gitea account with write access to at least one repository, limiting the attack surface to authenticated users.

1. Reconnaissance: Identify a target Gitea instance running a version prior to 1.25.4. Enumerate repositories and their Git LFS lock IDs using the Gitea API (e.g., GET /api/v1/repos/{owner}/{repo}/git/lfs/locks) from any repository the attacker has read access to.
2. Obtain a valid account: Acquire or use an existing Gitea account with write access to at least one repository on the target instance.
3. Identify target lock IDs: Query the LFS locks API for repositories the attacker does not own to collect lock IDs belonging to other projects.
4. Send cross-repository deletion request: Issue a DELETE or POST request to the LFS lock deletion endpoint (e.g., POST /api/v1/repos/{victim-owner}/{victim-repo}/git/lfs/locks/{lock_id}/unlock or the equivalent LFS batch API), supplying a lock ID from a repository the attacker does not own. Due to the missing ownership validation, the server processes the deletion.
5. Achieve impact: The targeted LFS lock is removed, disrupting the workflow of legitimate users in the victim repository and potentially enabling conflicting file modifications (GitHub PR #36344, GitHub Advisory).

• Logs: Gitea access logs showing LFS lock deletion requests (DELETE or unlock POST calls) where the authenticated user's repository context does not match the repository associated with the lock ID; repeated cross-repository LFS unlock API calls from a single user account.
• Application Behavior: Unexpected disappearance of Git LFS locks in repositories where no authorized team member performed an unlock; users reporting that their LFS locks were removed without their action.
• Network: API calls to /api/v1/repos/{owner}/{repo}/git/lfs/locks/{id}/unlock or LFS batch unlock endpoints originating from accounts that do not have a legitimate reason to interact with the target repository.

Upgrade Gitea to version 1.25.4 or later, which includes the fix backported via pull requests #36344 and #36349 (Gitea Release, Gitea Blog). Instances on Gitea Cloud are automatically upgraded during the maintenance window. As an interim measure, administrators should audit Git LFS lock histories for unauthorized deletions and review user access permissions to minimize the number of accounts with write access across repositories. No configuration-based workaround is available that fully mitigates the vulnerability without upgrading.

The Gitea project addressed this vulnerability as part of a broader security-focused patch release (v1.25.4), which included eight security fixes simultaneously (Gitea Release). The release received positive community reception on GitHub, with 40 users reacting to the release announcement. No significant independent researcher commentary or media coverage beyond standard vulnerability tracking sites has been identified.