CVE-2026-66849 in Giteainfo

Summary

by MITRE • 10/14/2026

Gitea's package registry grants authenticated users read access to packages owned by Limited-visibility users without excluding restricted accounts. A restricted user can enumerate and download those packages despite the visibility policy that should prevent this access. The issue affects user-owned package registries and exposes package contents across the intended authorization boundary.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Analysis

by VulDB Data Team • 10/14/2026

The vulnerability identified in Gitea's package registry represents a critical failure in access control mechanisms, specifically within the context of authenticated users interacting with packages governed by limited visibility policies. In typical software development workflows using platforms like Gitea, organizations rely on granular permission settings to restrict sensitive code artifacts from unauthorized personnel or external entities. The core technical flaw lies in the authentication and authorization logic that governs package retrieval requests. When a user attempts to access a package marked as having limited visibility, the system fails to adequately verify whether the requesting account is restricted or lacks the necessary explicit permissions defined by the owner of the package. Instead of enforcing strict isolation based on the visibility setting, the backend service grants read access simply because the requester possesses valid authentication credentials. This oversight effectively bypasses the intended security boundary, allowing any authenticated user who knows the package identifier to enumerate and download its contents regardless of their actual role or clearance level within the organization.

From a technical perspective, this issue is classified as an Insecure Direct Object Reference (IDOR) combined with Broken Access Control vulnerabilities. The system treats all authenticated sessions equally when processing read requests for private artifacts, neglecting to cross-reference the requester's identity against the specific access control lists associated with each package. This lack of proper object-level permission checks means that the confidentiality integrity of proprietary software components is compromised. Attackers can exploit this by systematically enumerating known or guessed package names and attempting downloads. Since the vulnerability does not require privilege escalation but rather exploits a logical flaw in existing permissions, it poses a significant risk to intellectual property protection and supply chain security within development teams using Gitea for artifact management.

The operational impact of this vulnerability is severe for organizations that depend on private repositories for their continuous integration and deployment pipelines. Unauthorized access to package registries can lead to the leakage of proprietary source code, configuration files containing secrets or API keys, and other sensitive data embedded within software packages. This exposure facilitates further attacks such as reverse engineering of proprietary algorithms, identification of vulnerable dependencies through dependency manifest analysis, or even sabotage if an attacker gains write access after initial reconnaissance. Furthermore, it undermines trust in the platform's security model, potentially violating compliance requirements related to data protection and intellectual property rights that mandate strict access controls for sensitive digital assets.

To mitigate this risk, immediate action is required to enforce stricter authorization checks within the package registry module. Developers must ensure that every request to retrieve a package verifies not only authentication but also explicit authorization based on the package's visibility settings and the user's assigned roles. Implementing robust access control lists that explicitly deny read operations for restricted users unless they are granted specific permission is essential. Additionally, organizations should audit their current Gitea instances for any existing exposure of limited-visibility packages and rotate any credentials or secrets potentially exposed through this flaw. Upgrading to a patched version of Gitea where these authorization checks have been corrected is the primary remediation strategy. Long-term security improvements include implementing regular access reviews and adopting principle of least privilege across all user accounts interacting with package registries. This vulnerability aligns with CWE-269 Improper Privilege Management and CWE-862 Missing Authorization, while in terms of tactical exploitation it relates to ATT&CK technique T1078 Valid Accounts where attackers leverage legitimate credentials to access resources they are not authorized to view.

Responsible

Gitea

Reservation

08/13/2026

Disclosure

10/14/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!