CVE-2026-117677 in Gitea
Summary
by MITRE • 11/01/2026
When parsing an uploaded Helm chart, Gitea decompressed the archive and read every tar entry while looking for `Chart.yaml` without limiting the decompressed size, and did so before the package size quota was checked; the quota only considers the compressed upload size. A user with package write access to an owner, for example their own account on an instance with open registration, could repeatedly upload small, highly compressed archives that make the server spend CPU time proportional to the decompressed size, degrading the availability of the Gitea instance. The issue does not allow code execution or data access.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/01/2026
The vulnerability identified in Gitea represents a significant resource exhaustion flaw rooted in the handling of Helm chart uploads. When a user submits a package for storage within the system, the application is designed to parse the uploaded archive to locate and validate specific configuration files, most notably Chart.yaml. The technical deficiency lies in the decompression logic, which fails to impose any limit on the size of the data after it has been extracted from its compressed format. This oversight occurs prior to the enforcement of package storage quotas, meaning that the system processes potentially massive amounts of uncompressed data before determining whether the upload should be rejected based on disk space constraints. Consequently, an attacker can exploit this sequence by uploading archives that are small in their compressed state but expand into extremely large files upon decompression.
This architectural flaw allows for a denial-of-service attack vector where availability is compromised without requiring elevated privileges or code execution capabilities. A user with package write access to any owner account, such as one created on an instance with open registration enabled, can repeatedly submit these maliciously crafted archives. Each upload forces the server to allocate CPU cycles and memory proportional to the decompressed size of the archive rather than its actual uploaded footprint. By continuously submitting small but highly compressible files that expand significantly when unpacked, an attacker can saturate system resources, leading to severe performance degradation or complete unavailability of the Gitea instance for legitimate users. The impact is strictly limited to availability; there is no mechanism within this specific flaw that permits arbitrary code execution or unauthorized access to sensitive data stored on the server.
From a classification perspective, this vulnerability aligns with CWE-400, which describes Uncontrolled Resource Consumption. It also maps closely to ATT&CK technique T1496, specifically representing Resource Hijacking through environmental exploitation where an adversary consumes resources to degrade service availability. The root cause is a failure in input validation and resource management during the archive processing phase, highlighting the importance of enforcing limits on decompressed data sizes regardless of the initial upload constraints.
Mitigation strategies must focus on implementing strict size limits for decompressed content within the Helm chart parsing logic. Developers should ensure that any temporary files or memory buffers allocated during extraction are capped at a reasonable maximum threshold consistent with typical Helm chart structures. Additionally, the order of operations in the package handling workflow should be reviewed to ensure that resource-intensive processes like full decomposition do not proceed until basic validity and size checks have been satisfied using safe metrics. Until such patches are applied, administrators may consider restricting public registration or limiting write permissions for packages to trusted users only, thereby reducing the attack surface available to potential abusers seeking to exhaust system resources.