External risk intelligence

Gitea Repository Ownership Validation Flaw Allows Cross-Repository LFS Lock Deletion.

CVE advisorySeverity: CRITICAL (CVSS 9.1)

CVE-2026-20897

Gitea is commonly deployed as an internet-facing or externally accessible web application for code hosting and collaboration. The vulnerability involves repository management functions that are exposed via the web interface and API, which are typically reachable in standard Gitea installations.

Gitea

before 1.25.4

Halo Surface Signal: 4 out of 5 — likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A vulnerability in Gitea, a code hosting platform, could allow an attacker to delete important files from repositories they do not own. This issue arises from improper validation of repository ownership during the deletion of Git Large File Storage (LFS) locks. While the full business impact is being assessed, the primary concern is to confirm if your organization uses Gitea and if it is exposed to this risk.

Unauthorized deletion of file locks.
Affects code integrity and access controls.
Confirm Gitea usage and exposure.

Attack Path

How an attacker could exploit the issue

An attacker could exploit this vulnerability by gaining write access to one repository and then deleting Git LFS locks that do not belong to them. This could lead to the deletion of crucial data associated with large files managed by Git LFS.

Requires write access to one repository.
Deleting Git LFS locks in other repositories.
Potential for data deletion or corruption.

Live Threat

Current exploitation, exposure, and threat context

This vulnerability could allow a user with write access to one repository to delete Git Large File Storage (LFS) locks belonging to other repositories. This could impact the integrity of LFS file locking mechanisms when supported by the advisory.

LFS lock data may be affected.
Unauthorized deletion of locks.
Disruption of LFS file management.

Operational Fix

Recommended remediation, mitigation, and detection steps

The Gitea team is likely responsible for addressing this vulnerability, given the context of code repository management. Initial steps should focus on identifying all Gitea instances, confirming their exposure and criticality, and then coordinating remediation efforts with the identified asset owners.

Ownership: Gitea administrators and platform teams.
Verify first: Confirm Gitea instance reachability and usage.
Action: Plan and execute vendor-coordinated updates.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is Gitea?

Gitea is a lightweight, self-hosted code hosting platform built on Git. Developers use it to manage software projects, track versions, and collaborate on codebases. It includes features like Git Large File Storage (LFS) support to handle heavy assets, which helps teams manage binary files that are too large for standard version control, ensuring smooth development workflows across distributed teams.

What does CVE-2026-20897 mean?

This vulnerability is an improper access control issue, specifically categorized as CWE-284 and CWE-639. It means the software fails to properly check if a user actually owns or has permission for a specific repository before allowing them to delete its LFS locks. Essentially, the system trusts a request to delete a lock without verifying that the requester has the right to modify that particular repository's files.

How can this vulnerability be triggered?

An attacker triggers this by having write access to at least one repository on the Gitea instance. If they possess this level of access, they can manipulate the LFS lock mechanism to delete locks belonging to other, unrelated repositories they do not own. Simply having an account without write access to any repository is not sufficient to exploit this flaw.

Is my Gitea instance at risk?

Halo Surface Signal indicates that Gitea is often deployed as an internet-facing application, making it reachable by external actors. Because the vulnerability involves core repository management functions accessible through the standard web interface or API, any Gitea instance reachable over a network is at a higher risk of being targeted compared to strictly internal, isolated systems.

What should I do to address CVE-2026-20897?

First, verify all Gitea instances running in your environment. Check the version of your installations; the vendor has released version 1.25.4 to resolve this ownership validation flaw. Coordinate with your platform teams to plan and apply the update to version 1.25.4 or later as soon as possible to restore proper LFS lock security.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.