CVE-2026-118504 in Gitea
Summary
by MITRE • 11/01/2026
The web interface blocks issue and pull request changes on archived repositories, but several issue routes of the REST API did not check whether the repository is archived. A user allowed to change issues of an archived repository could use the API to edit, close or delete issues, change labels and deadlines, add or delete tracked time and stopwatches, add reactions, change issue blocks, and pin issues, altering data that archiving is meant to freeze. Gitea 28.2.0 added the check to the issue edit, delete and label routes; Gitea 28.3.0 applies it to all modifying repository API requests.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/01/2026
The vulnerability described involves a discrepancy between the security controls implemented in the web interface of Git repositories and those applied through their REST application programming interfaces. Specifically, while the graphical user interface correctly prevents users from modifying issues or pull requests within archived repositories, several endpoints within the REST API failed to perform this same validation check. This inconsistency creates a significant bypass mechanism where an attacker with legitimate permissions can circumvent administrative restrictions designed to preserve repository integrity and historical data accuracy. The core technical flaw lies in the server-side logic for handling HTTP requests via the API; unlike the web interface which explicitly checks archive status before processing modifications, these specific API routes proceeded directly to execute state-changing operations without verifying whether the target repository had been marked as archived by an administrator.
The operational impact of this vulnerability is substantial because it allows unauthorized modification of data that archiving is specifically intended to freeze. An authenticated user with appropriate permissions could exploit these unchecked endpoints to edit, close, or delete issues entirely. Furthermore, they possess the ability to alter metadata such as labels and deadlines, manage tracked time entries and stopwatches associated with tasks, add or remove reactions from discussions, modify issue blocking relationships, and pin specific items to the top of lists. These actions effectively undermine the purpose of archiving a repository, which is typically to signal that development has ceased and to prevent accidental changes to historical records while preserving them for reference. By allowing these modifications through the API, the vulnerability compromises the immutability guarantees expected from archived projects, potentially leading to data integrity issues and confusion regarding project status.
From a classification perspective, this issue aligns with CWE-284 Improper Access Control, as it represents a failure in enforcing intended restrictions on authorized users based on resource state. It also relates to CWE-693 Protection Mechanism Failure because the security control present in one interface (web) was not consistently applied across all access vectors (API). In terms of adversary tactics, this could facilitate actions categorized under ATT&CK T1562 Impair Defenses if an attacker uses these capabilities to alter logs or issue states to obscure malicious activity or disrupt project workflows. The vulnerability highlights the importance of ensuring that security policies are uniformly enforced across all entry points into a system, particularly when different interfaces serve as gateways for similar operations.
Mitigation strategies focus on applying consistent validation logic across all API endpoints. As noted in the provided context, this issue was addressed by updating the software to version 28.2.0 and subsequently 28.3.0. The fix involved adding explicit checks within the code handling issue edit, delete, and label routes in version 28.2.0, followed by a comprehensive application of these archive status validations to all modifying repository API requests in version 28.3.0. Organizations running affected versions should upgrade immediately to ensure that archived repositories remain protected from unintended modifications via the REST API. Additionally, security teams should audit their CI/CD pipelines and automated scripts for any reliance on APIs that might interact with archived resources, ensuring they are updated to handle potential errors or restrictions gracefully after upgrading. Regular penetration testing that includes both web interface and API interaction scenarios is recommended to detect similar inconsistencies in other systems where partial implementation of access controls may exist.