CVE-2026-59766 in Gitea
Summary
by MITRE • 10/14/2026
Gitea's starred-repository and tracked-time API endpoints do not re-check current repository permissions before returning data associated with the requesting user. A user whose access to a private repository has been revoked can still retrieve repository metadata through /api/v1/user/starred and private issue titles through /api/v1/user/times. The disclosure depends on relationships or tracked-time entries created before access was revoked.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability in Gitea represents a critical authorization bypass within the user-facing API endpoints, specifically affecting the starred-repository listing and tracked-time functionalities. This flaw stems from an insufficient check of current repository permissions during data retrieval operations. When a user requests information via the /api/v1/user/starred endpoint or retrieves private issue titles through the /api/v1/user/times endpoint, Gitea fails to re-validate whether the requesting user retains active access rights to the specific repositories in question. Instead, the system relies on historical relationships and existing data associations that were established when the user previously had legitimate access. This architectural oversight allows individuals who have been explicitly revoked of their permissions for private repositories to continue extracting sensitive metadata, including repository details and issue titles, thereby undermining the intended security boundaries of the platform.
From a technical perspective, this is a classic example of an Insecure Direct Object Reference (IDOR) combined with broken access control logic. The application maintains stateful relationships such as star associations and time-tracking entries but does not enforce dynamic permission checks against these resources during read operations. While the initial creation or modification of these records likely involved proper authentication and authorization, the subsequent retrieval process lacks a mandatory verification step to ensure that the user's current role still permits access to the underlying private repository data. This discrepancy between write-time validation and read-time enforcement creates a persistent security gap that persists until the relationship is explicitly removed from the database or the application logic is patched to include real-time permission checks for every API response involving private resources.
The operational impact of this vulnerability is significant, particularly in environments where Gitea hosts sensitive proprietary codebases or confidential project information. An attacker with a revoked account can still enumerate and view metadata associated with private repositories they no longer have access to. This includes the ability to discover repository names, descriptions, and potentially issue titles which may contain architectural details, bug reports, or strategic planning information. Although direct source code download is not possible through these specific endpoints without further exploitation of other vulnerabilities, the leakage of metadata can aid attackers in reconnaissance efforts, helping them map out an organization's infrastructure, identify active projects, and gather intelligence for future attacks. This exposure violates the principle of least privilege and compromises the confidentiality guarantees expected from private repositories.
This vulnerability aligns with CWE-269 Improper Privilege Management, as it involves a failure to enforce proper authorization levels during API execution. It also maps closely to MITRE ATT&CK technique T1087 Account Discovery, where an adversary uses valid credentials or existing access patterns to gather information about accounts and resources within the environment. Furthermore, because the data is accessed via standard HTTP APIs without additional authentication checks at the point of retrieval, it falls under CWE-639 Authorization Bypass Through User-Controlled Key if one considers the repository ID as a user-controlled key that bypasses permission validation. The reliance on pre-existing relationships rather than current stateful permissions highlights a fundamental flaw in how access control lists are evaluated during read operations.
To mitigate this vulnerability, Gitea administrators and developers must ensure that all API endpoints returning data related to private repositories perform real-time authorization checks against the user's current role and permission set for each specific repository ID requested. This involves querying the database not just for the existence of a star or time entry, but also verifying that the associated repository is accessible by the requesting user at the moment of the request. If access has been revoked, the API should return an empty list or filter out those entries rather than exposing them. Additionally, implementing comprehensive logging and monitoring for these endpoints can help detect anomalous patterns where users with restricted permissions are still attempting to retrieve private data. Regular security audits focusing on authorization logic in read-heavy operations are essential to prevent similar bypasses in other parts of the application.