CVE-2026-97626 in Gitea
Summary
by MITRE • 10/07/2026
Requesting a user or organization profile page (`GET /{username}`) with an `Accept: application/rss+xml` or `Accept: application/atom+xml` header returned the owner's activity feed without the visibility check that the profile page and the `.rss` and `.atom` routes apply. Anonymous users, restricted users and non-members could confirm the existence of limited or private users and private organizations and read their profile details and public activity, also when `[other] ENABLE_FEED` was disabled. Activity in private repositories was not included.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/08/2026
The vulnerability described constitutes a critical access control failure within the web application's content delivery mechanisms, specifically affecting the RSS and Atom feed endpoints associated with user or organization profile pages. In standard secure architectures, public-facing information such as activity feeds must undergo rigorous visibility checks to ensure that sensitive data is not exposed to unauthorized entities. However, in this instance, the implementation of the GET endpoint for retrieving these feeds failed to enforce the same authentication and authorization logic applied to the primary HTML profile page or the dedicated RSS/Atom route handlers. This discrepancy creates a significant blind spot where the application serves content based on URL structure rather than consistent policy enforcement across all output formats.
From a technical perspective, this flaw represents an insecure direct object reference combined with broken access control principles. When a request is made to the profile endpoint using specific Accept headers indicating XML-based feed formats, the server bypasses the standard visibility filters that typically restrict data based on user roles and privacy settings. Consequently, anonymous users, restricted accounts, or individuals who are not members of an organization can successfully query these endpoints. The system incorrectly assumes that because the request is for a public format like RSS or Atom, it should be accessible to all, ignoring the underlying security context of the resource owner's account status. This allows attackers to enumerate valid usernames and organizations by observing HTTP response codes or content presence, effectively confirming the existence of private accounts even when such visibility is explicitly disabled in the application configuration via settings like ENABLE_FEED.
The operational impact of this vulnerability is severe regarding privacy and data leakage. Attackers can exploit this flaw to harvest profile details and public activity logs from limited or private user profiles that are intended to be hidden from general view. This capability facilitates reconnaissance activities, allowing adversaries to map out the organizational structure, identify key personnel, and gather intelligence on internal workflows without needing valid credentials for those specific accounts. While the vulnerability does not expose content within private repositories, which remains protected by separate repository-level permissions, the exposure of profile metadata and public activity streams provides valuable context that can be leveraged in subsequent social engineering attacks or targeted exploits against identified individuals.
This issue aligns with CWE-284 Improper Access Control, as the application fails to restrict information access for unauthorized actors. It also maps directly to MITRE ATT&CK technique T1087 Account Discovery, where adversaries use various methods to enumerate accounts within a system or network environment. The ability to confirm the existence of private entities through feed endpoints serves as an effective enumeration vector that bypasses standard UI-based restrictions. To mitigate this risk, developers must ensure that all output formats, including RSS and Atom feeds, implement identical access control checks as their HTML counterparts. This involves validating user permissions against the resource owner's privacy settings before generating any response payload. Additionally, implementing consistent middleware for visibility checks across all route handlers will prevent such discrepancies from occurring in future updates or similar endpoints within the application architecture.