External risk intelligence

Gitea LFS Bypass of Migration Transport Protections

CVE advisorySeverity: CRITICAL (CVSS 9.8)

CVE-2026-26292

Gitea is a self-hosted Git service frequently deployed as an internet-facing application to facilitate code collaboration, repository management, and synchronization. Because these services are commonly exposed to the internet to allow remote access for developers and automated systems, the vulnerable LFS push and sync mirror operations are likely to be reachable in many standard deployments.

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

This advisory addresses a vulnerability in Gitea, a widely used self-hosted Git service. The issue involves how the system handles large file transfers, potentially bypassing security controls when synchronizing or pushing code. While the technical details concern specific data transfer methods, the high-level implication is that an unauthenticated attacker could exploit this to access or manipulate code repositories, depending on how Gitea is configured and exposed.

Gitea bypasses security for large file transfers.
External access to code is a key concern.
Verify Gitea's exposure and impact.

Attack Path

How an attacker could exploit the issue

Attackers can exploit this vulnerability by targeting Gitea instances that have not been updated. The vulnerability allows attackers to bypass security protections related to Git Large File Storage (LFS) operations, potentially leading to unauthorized access and modification of data.

Unauthenticated network access required.
LFS push or sync mirror operations trigger.
Data compromise and integrity loss.

Live Threat

Current exploitation, exposure, and threat context

This vulnerability could affect the integrity and availability of Git Large File Storage (LFS) data managed by Gitea. When Gitea does not use the configured migration HTTP transport for LFS push and sync mirror operations, these operations bypass existing protections. This could lead to unauthorized modifications or unavailability of LFS data.

Git LFS data.
Unprotected LFS operations.
Data integrity and availability compromised.

Operational Fix

Recommended remediation, mitigation, and detection steps

Real-world action for this vulnerability requires identifying which teams manage Gitea instances, especially those exposed externally. The first step is to locate all deployments, determine their reachability and business criticality, and assign an accountable owner. Subsequent planning for remediation or mitigation should then be risk-based.

Own issue: Application or infrastructure teams.
Verify first: Confirm external exposure and critical use.
Action: Plan risk-based remediation.

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 and what is it used for?

Gitea is a lightweight, self-hosted platform used by teams to manage Git repositories and collaborate on code. It acts as a central hub for version control, offering features like code hosting, issue tracking, and repository synchronization. Organizations use it to keep their development workflows private and under their own control, rather than relying on third-party cloud hosting services.

What does CVE-2026-26292 mean by bypassing migration transport?

This vulnerability, classified as CWE-284 for improper access control, occurs because Gitea fails to route Git Large File Storage (LFS) operations through the intended security transport layer. By not using the configured migration HTTP transport during push or sync mirror tasks, the system effectively ignores the security policies meant to protect these data transfers, leaving the LFS data potentially exposed to unauthorized interaction.

How is this Gitea vulnerability triggered?

The vulnerability is triggered when a Gitea instance performs LFS push or sync mirror operations. An attacker can exploit this when the application is network-accessible. Importantly, simply having LFS enabled is not enough; the bug specifically requires the execution of these specific transfer operations while the software is in an unpatched state. It does not affect standard repository operations that do not involve these specific LFS transport pathways.

Why should I care about this if my Gitea instance is internal?

Halo Surface Signal indicates that Gitea is frequently deployed as an internet-facing application to support remote developer workflows. While internal instances face lower risk than those directly exposed to the internet, you should still evaluate whether your specific deployment allows for remote access by automated systems or external contributors, as these configurations may increase the likelihood that an attacker can reach the vulnerable LFS operation pathways.

What should I do if I run Gitea?

First, identify all Gitea instances within your organization and verify their version numbers. If you are running a version earlier than 1.25.5, prioritize upgrading to the latest release to apply the necessary security fixes. Coordinate with your application or infrastructure teams to determine which instances are internet-facing or critical to business operations, and plan your update schedule based on that risk assessment.

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.