CVE-2026-20883 in Gitea
Summary
by MITRE • 01/23/2026
Gitea's stopwatch API does not re-validate repository access permissions. After a user's access to a private repository is revoked, they may still view issue titles and repository names through previously started stopwatches.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 01/24/2026
The vulnerability identified as CVE-2026-20883 represents a critical authorization bypass flaw within Gitea's stopwatch API implementation. This issue stems from the application's failure to perform proper access validation when retrieving stopwatch data, creating a persistent security weakness that allows unauthorized users to access sensitive repository information even after their permissions have been revoked. The flaw specifically affects private repositories where users previously had access but whose permissions have since been withdrawn by administrators.
The technical root cause of this vulnerability lies in the stopwatch API's design pattern which caches or stores stopwatch data without re-validating the requesting user's current permissions. When a user initiates a stopwatch on an issue within a private repository, the system records this activity but fails to verify that the user still maintains valid access rights when the stopwatch data is subsequently retrieved. This design oversight creates a window of opportunity where revoked access can be exploited through existing stopwatch records that contain issue titles and repository names.
From an operational perspective, this vulnerability poses significant risks to organizations relying on Gitea for code repository management and collaboration. Attackers or former employees with revoked access can continue to gather intelligence about private repositories, including sensitive issue titles that may reveal implementation details, security vulnerabilities, or business-critical information. The impact extends beyond simple information disclosure as it undermines the fundamental access control mechanisms that protect private codebases and sensitive development artifacts from unauthorized access.
The vulnerability aligns with CWE-285, which addresses improper authorization in software systems, and demonstrates characteristics consistent with ATT&CK technique T1078.004 related to valid accounts and privilege escalation through access control bypass. Organizations using Gitea should consider this vulnerability as part of their broader security posture assessment, particularly in environments where sensitive source code and development data are stored in private repositories. The persistence of this access through previously initiated stopwatches indicates a systemic flaw in the application's permission model that requires immediate attention.
Mitigation strategies should include implementing immediate re-validation of repository access permissions whenever stopwatch data is retrieved, regardless of when the stopwatch was initiated. Organizations should also consider implementing session-based access controls that invalidate cached stopwatch data when user permissions change, and establish monitoring mechanisms to detect unusual access patterns to previously revoked repositories. Additionally, the application should be updated to ensure that all stopwatch-related API endpoints perform proper authentication checks before returning any repository information, preventing the leakage of issue titles and repository names to unauthorized users.