CVE-2026-67577 in Gitea
Summary
by MITRE • 10/14/2026
Gitea's activity-feed and contribution-heatmap API handlers do not apply the profile visibility check for restricted accounts viewing Limited-visibility users. A restricted user can retrieve activity records and contribution timestamps that the corresponding profile routes deny. Exposed activity can include repository names, commit messages, and issue or pull request events associated with qualifying public-repository activity.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability in Gitea represents a critical authorization bypass within its social interaction features, specifically affecting the API endpoints responsible for generating user activity feeds and contribution heatmaps. In secure software architecture, access control mechanisms must be consistently applied across all entry points to prevent privilege escalation or information disclosure. However, this implementation flaw allows restricted users to retrieve sensitive data that is explicitly withheld when accessing standard profile pages. The core technical deficiency lies in the failure of the activity-feed and heatmap handlers to enforce the same visibility checks performed by user profile routes. When a user with limited permissions attempts to view another user's public-facing information through these specific API endpoints, the system fails to verify whether the target account is restricted or if the viewing user lacks the necessary privileges to see that data. This inconsistency creates an unauthorized access vector where logic intended for open profiles is incorrectly applied to protected contexts.
The operational impact of this vulnerability centers on the exposure of granular activity metadata associated with public repositories, even when such visibility should be denied based on account restrictions. Restricted accounts in Gitea are designed to limit the amount of personal and professional information visible to other users, often for privacy or security reasons. Despite these restrictions, an attacker can query the affected API endpoints to obtain a detailed timeline of events including repository names, specific commit messages, and issue or pull request activities linked to public repositories. While the underlying content resides in public repositories, the aggregation and association of this data with specific user identities constitute sensitive information leakage. This exposure allows for enhanced profiling of target users, potentially revealing development patterns, project involvement levels, and technical interests that were intended to remain obscured from restricted viewers.
From a classification perspective, this issue aligns closely with CWE-284 Improper Access Control, as the system fails to enforce proper restrictions on authorized access levels. Furthermore, it relates to CWE-601 URL Redirection to Untrusted Site or Open Redirect if considered in terms of data flow integrity, but more accurately fits CWE-798 Use of Hard-coded Credentials or similar logic flaws depending on implementation details, though the primary classification remains an authorization bypass. In the context of the MITRE ATT&CK framework, this vulnerability facilitates Reconnaissance activities, specifically under techniques related to Gathering Victim Identity Information and Gathering Victim Organization Information. Attackers can leverage these API endpoints to build comprehensive profiles of target developers or organizations without triggering standard access control alerts associated with profile page visits.
Mitigation strategies must focus on ensuring consistent application of visibility rules across all API handlers within the Gitea codebase. Developers should audit the activity-feed and contribution-heatmap logic to explicitly check for restricted account status before returning any data, mirroring the checks performed in user profile routes. Implementing a centralized authorization middleware or service that validates access permissions prior to processing requests would prevent such inconsistencies. Additionally, security testing procedures should include automated regression tests that verify visibility constraints are enforced uniformly across all endpoints serving user-specific activity data. Until patched, administrators may consider restricting API access for restricted accounts through network-level controls or WAF rules as a temporary workaround while monitoring logs for unusual query patterns targeting these specific endpoints.