Listen to this Post
This vulnerability exists in the `/repos/{owner}/{repo}/locks/{id}` API endpoint responsible for deleting Git Large File Storage (LFS) locks. Git LFS locks prevent concurrent modification of large files by different users. The endpoint correctly verifies a user’s authentication and their general write permissions to a repository. However, it fails to perform a critical secondary validation: it does not check if the targeted lock ({id}) actually belongs to the repository specified in the request path ({owner}/{repo}). The system only validates that the authenticated user has write access to the repository provided in the URL parameters. Consequently, an attacker can construct a request targeting a valid lock ID from a victim’s repository while specifying a different repository where they have write access. The flawed authorization logic passes because the user has write access to the repository in the URL, allowing them to delete the LFS lock from the unrelated, victim repository. This breaks the integrity of the locking mechanism, potentially leading to merge conflicts and data corruption for projects using Git LFS.
Platform: Gitea
Version: 1.22.0-dev to 1.22.4
Vulnerability : Improper Lock Authorization
Severity: Moderate
Date: Jan 22 2026
Prediction: Patch by late-January 2026
What Undercode Say:
Simulating API call to vulnerable endpoint curl -X DELETE "https://gitea.example.com/api/v1/repos/attacker/repo/locks/12345" \ -H "Authorization: token $USER_TOKEN" Lock ID 12345 actually belongs to 'victim/repo'
Proof-of-Concept: Deleting foreign lock
import requests
lock_id = get_victim_lock_id() Lock from repo 'victim/project'
api_url = f"https://target/api/v1/repos/attacker/my_repo/locks/{lock_id}"
headers = {"Authorization": f"token {ATTACKER_TOKEN}"}
requests.delete(api_url, headers=headers) This succeeds improperly
How Exploit:
Attacker with write access to any repository identifies a target LFS lock ID from a different project (e.g., via API enumeration or prior access). They then send a DELETE request to the vulnerable endpoint, specifying their own repository in the URL path but the victim’s lock ID. The attack is performed remotely via the web API.
Protection from this CVE
Upgrade to Gitea 1.22.5 or later, where the patch validates repository ownership. Implement network segmentation for CI/CD runners. Use API security gateways to monitor for anomalous lock deletion patterns. Restrict user repository write permissions to only necessary projects.
Impact:
Disruption of Git LFS workflows, potential file corruption, and merge conflicts. Compromises integrity of collaborative development on large assets. Low attack complexity but requires valid user account with write privileges somewhere on the instance.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
