CVE-2026-60018 in Gitea
Summary
by MITRE • 10/15/2026
Gitea's OneDev migration downloader reads the entire remote version response into memory without a size limit and uses a client without a timeout. An authenticated user who can start a repository migration can direct it to an attacker-controlled OneDev-compatible server returning an oversized or never-ending response. This can consume memory and hold migration workers, impairing service availability.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in Gitea represents a significant resource exhaustion risk stemming from improper input validation and configuration of network client parameters during the repository migration process. Specifically, when initiating a migration to or from a OneDev-compatible server, the application's downloader component fails to enforce any upper bound on the size of the remote version response data it retrieves. Furthermore, the underlying HTTP client used for this operation is configured without an explicit timeout mechanism. This combination creates a scenario where the application does not anticipate or handle unexpectedly large payloads or unresponsive network endpoints effectively, leading directly to resource depletion within the Gitea environment.
From a technical perspective, the flaw lies in the lack of defensive programming practices regarding external data ingestion and connection management. By reading the entire remote response into memory without checking its size against available system resources, the application becomes susceptible to denial-of-service conditions if an attacker controls the target server or can manipulate DNS responses to point to a malicious endpoint. The absence of a timeout means that even if the payload is not excessively large but simply slow to respond or hangs indefinitely, the migration worker thread remains occupied for an indefinite period. This prevents the worker from handling other legitimate requests, effectively creating a bottleneck that degrades overall system performance and availability.
The operational impact of this vulnerability is primarily centered on service availability rather than data confidentiality or integrity. An authenticated user with permissions to start repository migrations can exploit this flaw by directing the migration process toward an attacker-controlled OneDev-compatible server. This server can be configured to return a response that exceeds available memory, causing the Gitea instance to crash due to out-of-memory errors, or it can simply delay its response indefinitely. In either case, the result is the exhaustion of migration worker resources and potentially the entire application heap, leading to a denial of service for other users attempting to access the platform. This aligns with CWE-400, which describes uncontrolled resource consumption, as well as CWE-770, regarding allocation of resources without limits or thresholds.
In terms of threat modeling, this vulnerability facilitates an attack vector consistent with ATT&CK technique T1496, Resource Hijacking, specifically through denial of service via resource exhaustion. The attacker leverages authenticated access to trigger a computationally expensive and unbounded operation that consumes system resources disproportionately relative to the task's intended scope. This is particularly dangerous in multi-tenant environments or shared hosting scenarios where one user's actions can directly impact the stability of the entire platform for all other users.
Mitigation strategies should focus on implementing strict limits on data ingestion and enforcing robust timeout policies. Developers must configure the HTTP client used for migrations to include reasonable read, write, and connection timeouts that align with expected network latency profiles. Additionally, a maximum response size limit should be enforced at the application level before or during the reading of the remote version response. If the incoming data exceeds this threshold, the migration process should fail gracefully rather than attempting to allocate unbounded memory. Input validation for URL targets is also recommended to restrict migrations to trusted domains where possible, although client-side controls remain essential given that authenticated users can specify arbitrary URLs. Regular security audits and penetration testing focused on resource exhaustion scenarios are advised to ensure these safeguards function correctly under load.