CVE-2026-104633 in Gitea
Summary
by MITRE • 10/07/2026
When migrating a repository from another Gitea instance, Gitea used the page size reported in the source server's API settings to end its paginated downloads. A source that reported `max_response_items` as `0` made these loops run indefinitely and grow server memory until it was exhausted. Any user who can migrate repositories could point a migration at a server they control and cause a denial of service.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability described involves a critical flaw in the repository migration functionality within Gitea, specifically concerning how pagination parameters are handled during data transfer from external sources. When an administrator or authorized user initiates a migration process to import repositories from another Gitea instance, the application queries the source server's API to retrieve metadata and content. A key component of this interaction is the determination of page size for paginated requests, which dictates how many items are fetched in each batch. The flaw arises because Gitea blindly trusts the max_response_items value reported by the source server without performing adequate validation or imposing local limits on this parameter.
In standard API pagination implementations, a zero or null value typically indicates that there is no limit and all results should be returned at once, or it may indicate an error in configuration. However, Gitea interpreted a max_response_items setting of 0 as an instruction to fetch items with infinite volume, leading to an unbounded loop. Instead of breaking the pagination cycle when appropriate conditions are met or applying a reasonable upper bound based on local system capabilities, the application continued requesting data indefinitely. This behavior transforms what should be a controlled batch processing operation into an endless stream of memory allocations as each page of results is loaded into server memory for processing and storage.
The operational impact of this vulnerability is severe, primarily manifesting as a denial of service against the target Gitea instance. Because the migration process consumes increasing amounts of RAM with every iteration of the loop, the affected server will eventually exhaust its available memory resources. This resource exhaustion leads to system instability, potential crashes of the application or underlying operating system services, and unavailability for legitimate users. The severity is compounded by the fact that repository migrations are often performed by trusted administrators who may not anticipate malicious behavior from a source they control. An attacker can easily set up a rogue Gitea instance configured with max_response_items equal to zero and trick an administrator into migrating repositories from it, thereby triggering this memory exhaustion attack vector without requiring any additional authentication or privilege escalation beyond the ability to initiate migrations.
From a vulnerability classification perspective, this issue aligns closely with CWE-400, which describes uncontrolled resource consumption. The lack of input validation on external data regarding pagination limits is also indicative of CWE-20, improper input validation. In terms of attack tactics as defined by MITRE ATT&CK, this scenario exemplifies the Resource Hijacking technique where an attacker consumes significant amounts of computing resources to degrade service availability for other users. It falls under the broader category of Denial of Service attacks that target application-level logic rather than network bandwidth or infrastructure capacity directly.
To mitigate this vulnerability, immediate remediation should focus on implementing strict bounds checking on pagination parameters received from external sources. The Gitea instance must enforce a maximum page size limit regardless of what the source server reports, ensuring that memory usage remains predictable and bounded during migration operations. Additionally, introducing timeout mechanisms or progress indicators with abort capabilities can help prevent long-running processes from consuming excessive resources if they behave unexpectedly. Administrators should also be advised to only migrate repositories from trusted sources until such patches are applied globally across all instances in their ecosystem. Updating the Gitea software to a version that includes fixes for this pagination handling logic is essential to restore secure operation and protect against exploitation by malicious actors seeking to disrupt service availability through resource exhaustion attacks.