Gitea: Helm chart upload decompresses without a size limit before the quota check, allowing CPU exhaustion

Impact

Gitea decompresses an uploaded Helm chart archive and walks every tar entry looking for Chart.yaml before the package size quota is applied, and the quota only counts the compressed bytes. A user with package write access - on an instance with open registration, their own account is enough - can upload a stream of small, highly compressed archives and make the server burn CPU proportional to the decompressed size. Where Gitea is the internal git and chart registry for a GPU fleet, that degrades the service CI jobs and GitOps controllers pull from, so deploys and image or chart fetches stall even though no GPU node is itself attacked. No code execution and no data access.

Who can reach it

Any authenticated Gitea user with package write access to an owner, reachable over HTTP; on an instance with open registration that is effectively anyone who can register.

What to do

Upgrade to Gitea 28.3.0 (fixes in PRs 39942 and 40085) and restart the Gitea service. As an interim measure, close open registration or remove package write access from untrusted accounts so only known users can push charts.

References

Related entries

• Apache CloudStack: unsanitized backup repository options inject OS commands onto the KVM hypervisor hostCVE-2026-47359 · Apache CloudStack NAS backup provider (addBackupRepository / updateBackupRepository)Unscored
• Apache Airflow: Connection and Variable secrets stored in cleartext in audit log rowsCVE-2026-50204 · Apache Airflow (audit log / event-log API)Unscored
• DMTF SPDM specification DSP0274 1.4 (FINISH transcript definition): A specification-level defect rather thanCVE-2026-61810 · DMTF SPDM specification DSP0274 1.4 (FINISH transcript definition)Unscored
• Linux x86/mm - broadcast TLB flush with PCID disabled: Booting with nopcid clears the PCID feature but broadcast TLBCVE-2026-64229 · Linux x86/mm - broadcast TLB flush with PCID disabledUnscored
• Linux crypto/ccp - SNP initialization on ioctl(SNP_COMMIT): The ccp driver initialised SNP from the SNP_COMMIT ioctlCVE-2026-64309 · Linux crypto/ccp - SNP initialization on ioctl(SNP_COMMIT)Unscored
• Linux iommu/amd - IRQ-unsafe locking in guest domain allocation: An IRQ-unsafe lock taken during AMD IOMMU guest domainCVE-2026-68347 · Linux iommu/amd - IRQ-unsafe locking in guest domain allocationUnscored