Live › vulnerability › CVE-2026-117677
Gitea decompresses uploaded Helm chart archives without a size limit before checking the package quota, which only counts the compressed size. A user with package write access can upload small, highly compressed archives that force heavy CPU use, slowing or degrading the instance; the sources state it does not allow code execution or data access.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-11-01 10:49 UTC. All times on this page are UTC.
Teams running a self-hosted Gitea instance that serves the packages registry and accepts Helm chart uploads. Exposure is greater where registration is open or many users have package write access to an owner; instances that do not use the Helm package type or restrict uploads can skip it.
No product ranges from the sources yet.
gitea --version or the admin dashboard and compare it to the fixed version (unknown in sources).No fix yet, per the sources.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-117677")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.