CVE-2026-117646 in Gitea
Summary
by MITRE • 11/01/2026
The repositories, stars and watching tabs of user profiles and the repository list of organization home pages included private repositories for every signed-in request without checking whether the request used a personal access token restricted to public resources (`public-only`). A holder of such a token could list the private repositories visible to the token's owner, and that user's stars and watches of private repositories. The API and the profile activity tab already applied the restriction. The impact is disclosure of repository names and metadata, not of repository content.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/01/2026
A significant information disclosure vulnerability was identified within GitHub’s web interface regarding the handling of authentication scopes for personal access tokens. Specifically, certain endpoints responsible for displaying user profiles and organization home pages failed to enforce scope restrictions when rendering data related to private repositories. The affected areas included the list of repositories owned by a user or organization, as well as the tabs showing starred repositories and watched items within those profiles. While other parts of the platform, such as specific API endpoints and the profile activity tab, correctly implemented checks to restrict access based on token permissions, these particular UI components overlooked this critical security control. This inconsistency allowed authenticated users holding personal access tokens with limited privileges to view sensitive information that should have been inaccessible under their current authorization level.
The technical flaw stems from a failure in server-side logic to validate the scope of the incoming request against the visibility requirements of private resources. When a user presents a personal access token designated as public-only, meaning it is restricted to accessing only publicly available data, the system incorrectly proceeded to fetch and display metadata associated with private repositories. This oversight meant that any individual possessing such a limited-scope token could enumerate the names and basic metadata of private repositories belonging to other users or organizations. The vulnerability effectively bypassed the intended isolation between public and private resource visibility, creating an unauthorized information leak path through standard web requests rather than requiring complex exploitation techniques.
The operational impact of this vulnerability is primarily categorized as a disclosure of sensitive repository identifiers and associated metadata. Although the actual source code, issues, pull requests, or other content within these private repositories remained secure and inaccessible, the exposure of repository names can still be detrimental to an organization’s security posture. Knowledge of existing private projects allows attackers to map out an target’s development activities, identify potential technologies in use, and infer project structures. This intelligence gathering capability facilitates further reconnaissance efforts, potentially aiding in more targeted attacks such as social engineering or supply chain compromises. The impact is strictly limited to metadata disclosure, but the value of this information for subsequent attack phases should not be underestimated.
This vulnerability aligns with CWE-200, which defines an Information Exposure where sensitive information is disclosed without explicit authorization. From a threat modeling perspective using MITRE ATT&CK techniques, this behavior corresponds to T1087, Account Discovery, as it allows an attacker to enumerate accounts and associated resources based on their visibility settings. It also touches upon T1539, Potential Data Exfiltration via Web Service, although in this case the exfiltration is passive through enumeration rather than active data theft. The root cause highlights a common challenge in web application security where different components of an application may have inconsistent implementations of access control policies, leading to gaps that attackers can exploit by targeting less rigorously protected endpoints or UI elements.
To mitigate such vulnerabilities, developers must ensure consistent enforcement of authorization checks across all user-facing interfaces and API endpoints. It is essential to implement a centralized authentication middleware that validates token scopes before processing any request involving private resources. Regular security audits should focus on identifying discrepancies in access control logic between different parts of the application architecture. Additionally, adopting a principle of least privilege for service accounts and personal tokens helps limit the blast radius if such flaws are present. Organizations relying on GitHub or similar platforms should monitor their token usage policies to ensure that public-only tokens do not inadvertently gain visibility into private assets through UI-based enumeration vectors.