CVE-2026-119627 in Gitea
Summary
by MITRE • 11/01/2026
The web profile and RSS/Atom feed routes of users and organizations checked only whether a signed-in viewer could see a limited-visibility owner, without considering the `public-only` restriction of the personal access token used to authenticate. Any user holding a public-only token could send it over HTTP Basic authentication to read the profile and activity feed of limited-visibility users and organizations, which are hidden from anonymous visitors and refused on the equivalent API routes. The disclosure covers existence, profile metadata and public activity; it does not grant write access.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 11/01/2026
This vulnerability represents a critical authorization bypass within GitHub's web interface and RSS/Atom feed endpoints, stemming from an inconsistency in how authentication tokens are validated against resource visibility policies. The core technical flaw lies in the server-side logic that processes requests for user profiles and organization activity feeds. When a request is made to these routes, the system correctly verifies whether the authenticated viewer has permission to view the target entity if it were publicly accessible or within their network. However, the implementation fails to cross-reference this check with the specific scope restrictions of the Personal Access Token (PAT) used for authentication. Specifically, tokens designated as public-only are intended to restrict access to only public repositories and resources. The vulnerability arises because the web profile and feed routes do not enforce this token-level restriction, allowing a user possessing such a limited-scope token to bypass visibility controls that would normally block anonymous or unauthorized viewers.
The operational impact of this flaw is significant for organizations and users who rely on private profiles or restricted organizational feeds as part of their security posture. An attacker with any valid GitHub account can generate a public-only Personal Access Token, which requires minimal privileges and poses little risk if compromised in isolation due to its limited scope. By sending HTTP Basic authentication headers containing this token to the affected web profile and RSS/Atom feed endpoints, the attacker can retrieve sensitive information that is explicitly hidden from anonymous visitors and blocked by standard API routes designed with proper authorization checks. The disclosed data includes the existence of the user or organization, their public profile metadata such as usernames and bios, and a log of their recent public activity. While this does not grant write access to private repositories or allow modification of account settings, it facilitates reconnaissance activities that can aid in further attacks, social engineering campaigns, or targeted phishing efforts by revealing active users and organizational structures that were intended to be opaque.
From a classification perspective, this vulnerability aligns with CWE-284, Improper Access Control, as the application failed to enforce proper authorization checks for different types of authenticated requests. It also relates to CWE-601, URL Redirection to Untrusted Site, in terms of how external-facing endpoints were exposed without adequate scope validation, though primarily it is an access control issue where the context switching between API and web routes led to inconsistent security enforcement. In the MITRE ATT&CK framework, this behavior corresponds to T1087, Account Discovery, as it allows an adversary to enumerate valid accounts and gather profile information from within a trusted network or via authenticated sessions that should have been restricted. The flaw highlights the danger of maintaining separate code paths for web interfaces versus API endpoints without ensuring consistent security policies across both vectors.
Mitigation strategies must focus on enforcing uniform authorization logic regardless of the access vector used to reach the resource. Developers should ensure that all entry points, including legacy routes like RSS feeds and profile pages, validate not only the user's relationship to the target entity but also the scope limitations of the authentication credential presented. Implementing a centralized middleware or service layer for permission checks can prevent such discrepancies by ensuring that token scopes are consistently applied across all application endpoints. Additionally, security teams should audit existing routes for similar inconsistencies where API-level restrictions might not be mirrored in web-based views. For immediate risk reduction, organizations should monitor logs for unusual access patterns involving public-only tokens accessing private profile data and rotate any potentially exposed credentials to invalidate the compromised tokens until a permanent patch is deployed by the vendor.