CVE-2026-107686 in Gitea
Summary
by MITRE • 10/18/2026
The Gitea web handlers for adding and removing reactions on issues and comments did not refuse locked issues for users without write access, although the API did. A signed-in user who could read an issue could therefore add or remove reactions on a locked issue and its comments, bypassing the interaction restriction of the lock. Only reactions were affected; no content could be changed.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability identified in Gitea represents a significant inconsistency between API-level access controls and web interface enforcement mechanisms regarding reaction management on restricted issues. Specifically, while the application's Application Programming Interface correctly enforced restrictions by refusing requests to add or remove reactions from locked issues for users lacking write permissions, the corresponding HTTP handlers responsible for rendering these actions within the web user interface failed to perform equivalent validation checks. This discrepancy creates a security gap where the logical enforcement of access policies is fragmented across different layers of the application architecture, allowing attackers who possess only read-level privileges on an issue or comment to bypass intended interaction restrictions through direct manipulation of web requests rather than relying solely on the API endpoints that were properly secured.
From a technical perspective, this flaw constitutes a Broken Access Control vulnerability where the server-side logic governing state-changing operations is not uniformly applied across all entry points for similar functionalities. When a user interacts with the Gitea interface to add or remove emoji reactions from an issue marked as locked, the backend handler processes the request without verifying whether the target resource has been restricted by administrators. In contrast, direct API calls are correctly intercepted and rejected if the user does not hold write access rights. This inconsistency suggests that the middleware or authorization logic applied to web handlers was either omitted during development or configured differently than the stricter policies enforced on RESTful endpoints, leading to a situation where the visual representation of permissions in the UI did not align with the actual backend enforcement mechanisms for this specific action type.
The operational impact of this vulnerability is primarily related to policy evasion and potential social engineering risks rather than data integrity compromise. Since only reactions can be added or removed, an attacker cannot alter issue content, delete comments, or modify repository settings through this flaw. However, by bypassing the lock mechanism, a user with read-only access can still engage in interactive behaviors that administrators intended to suppress on locked issues. This could facilitate unwanted noise, harassment, or coordinated manipulation of sentiment indicators within closed discussions. For organizations using Gitea for sensitive project management where locking issues is part of their workflow governance, this flaw undermines the integrity of those controls and may lead to confusion regarding which interactions are permitted in archived or restricted threads.
This issue aligns with CWE-269, Improper Privilege Management, as it involves a failure to enforce proper privileges for users who do not have sufficient permissions to perform specific actions on locked resources. Furthermore, from the perspective of adversary tactics, this behavior can be mapped to MITRE ATT&CK technique T1078, Valid Accounts, specifically in the context of abusing legitimate access rights to bypass security controls designed to limit interaction scope. The vulnerability highlights a common pattern where developers secure API endpoints rigorously but overlook equivalent checks for web-based form submissions or AJAX calls that trigger similar backend functions.
To mitigate this risk, Gitea administrators should ensure they are running a version of the software that includes patches addressing this specific access control inconsistency. Until an update is applied, monitoring logs for unusual reaction activity on locked issues may help detect exploitation attempts. For developers maintaining custom instances or forks, it is critical to audit all web handlers associated with issue and comment interactions to verify that authorization checks are identical to those implemented in the API layer. Ensuring uniform enforcement of access policies across both programmatic interfaces and graphical user interface endpoints is essential for maintaining robust security postures in collaborative development platforms.