CVE-2026-105964 in Gitea
Summary
by MITRE • 10/18/2026
The Gitea Actions artifact v4 (Twirp) handlers read the whole request body into memory without a size limit. A user who can run a workflow and obtains the runner token of that run could send an oversized request to the artifact service and exhaust the memory of the server, which terminates the Gitea process. The request body is now limited to 1 MiB.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability identified in Gitea Actions artifact v4 involves a critical resource management flaw within the Twirp-based handlers responsible for processing artifact uploads and retrievals. Specifically, these handlers were designed to read the entire contents of an incoming HTTP request body into server-side memory without implementing any upper bound on the size of that data. This architectural decision creates a direct path for denial-of-service attacks against the Gitea instance, as the application does not validate or constrain the volume of data it accepts from clients before attempting to allocate sufficient heap space to store it.
The operational impact of this flaw is severe and immediate. An attacker who possesses the ability to execute workflows within the Gitea environment can leverage their access to obtain the runner token associated with a specific run. With this authentication credential, the attacker gains the necessary permissions to interact directly with the artifact service endpoints. By constructing and sending an HTTP request containing a payload significantly larger than the available server memory or system limits, the attacker forces the application to consume excessive resources in an attempt to buffer the input. This uncontrolled resource consumption leads to rapid memory exhaustion on the host machine.
When the server's memory is fully consumed by these malicious requests, the Gitea process becomes unstable and ultimately terminates due to out-of-memory conditions or operating system intervention. This results in a complete denial of service for all users attempting to access the platform, effectively halting continuous integration and deployment pipelines that rely on the instance. The attack vector relies heavily on social engineering or prior compromise to gain workflow execution rights, but once achieved, it allows for a straightforward and highly effective disruption of service without requiring complex exploitation techniques beyond sending large data packets.
To mitigate this vulnerability, Gitea has implemented a strict limit on request body size, capping it at 1 MiB for artifact operations. This constraint ensures that even if an attacker attempts to exploit the handler by uploading excessively large files, the server will reject requests exceeding this threshold before they can consume significant memory resources. Administrators should ensure their Gitea instances are updated to a version containing this fix. Additionally, defense-in-depth strategies such as configuring reverse proxies like Nginx or Apache to enforce request size limits at the network edge can provide an additional layer of protection against oversized payloads reaching the application logic.
From a classification perspective, this vulnerability aligns with CWE-787: Out-of-bounds Read and CWE-400: Uncontrolled Resource Consumption. The failure to limit resource allocation based on untrusted input is a classic example of improper validation leading to system instability. In terms of adversarial tactics, this exploitation method corresponds to the ATT&CK technique T1499: Endpoint Denial of Service, specifically under the sub-technique for resource exhaustion via application layer attacks. Understanding these classifications helps security teams prioritize patching efforts and configure monitoring tools to detect similar patterns in future versions or related services within the ecosystem.