CVE-2026-128365 in Gitea
Summary
by MITRE • 11/15/2026
Removing a team's review request looked up a review by the negated team ID, which for the team with ID 2 is the ID of the built-in Actions user, and marked the review it found as official. In the organization that owns that team, a user who can change the review requests of a pull request could make an approval left by the Actions user count toward the approvals required by branch protection. Merging still required permission to merge. Removing a team review request no longer changes any review.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/15/2026
The vulnerability described involves a logic error in the handling of code review requests within a version control platform, specifically affecting how pull request reviews are processed when associated with specific teams. The core technical flaw lies in an integer negation operation used to identify and remove team-based review requirements. When a user initiates the removal of a review request for a particular team, the system calculates a lookup key by negating the team's unique identifier. This approach relies on the assumption that no other entity within the platform shares the same negative value as any valid positive team ID. However, this assumption fails in environments where specific reserved or built-in user accounts exist with identifiers that correspond to these negated values.
In the specific instance cited, a team with an internal identifier of 2 triggers this flaw because its negation results in -2. The platform's database contains a built-in system account, often referred to as Actions for automation purposes, which is assigned the user ID of -2 or effectively maps to it during lookup operations due to how negative IDs are resolved internally. Consequently, when an administrator attempts to remove a review request from team 2, the backend logic incorrectly interprets this action as targeting the built-in Actions user rather than the intended team. This misidentification leads to the system locating and modifying the review status of the Actions account instead of the team's pending requests.
The operational impact of this vulnerability is significant for organizations utilizing branch protection rules that require specific approvals before code can be merged. Branch protection policies often mandate that certain reviews, such as those from designated teams or users, must be marked as official to satisfy merge criteria. By erroneously marking a review left by the built-in Actions user as official during the removal process of an unrelated team's request, attackers or malicious insiders with permission to modify pull request settings can manipulate these approval states. This allows them to artificially inflate the number of valid approvals for a pull request without actually securing legitimate consensus from the required stakeholders. The vulnerability essentially bypasses the intended control flow by exploiting the misattribution of review authority.
This flaw aligns closely with CWE-841, which describes Improper Enforcement of Behavioral Workflow, as it allows an actor to deviate from the expected sequence of operations regarding approval validation. Furthermore, in the context of the MITRE ATT&CK framework, this behavior can be categorized under Tactic TA0005: Defense Evasion and Technique T1648: Suppression of Security Tools or more broadly as manipulation of access control mechanisms to bypass safeguards. The attacker leverages a legitimate administrative function—removing review requests—to achieve an unauthorized outcome regarding code approval status, thereby evading the security controls designed to ensure code quality and safety before deployment.
Mitigation strategies must focus on correcting the underlying logic error in the ID resolution process. Developers should avoid using simple negation of identifiers for lookup purposes unless there is a guaranteed disjoint set between positive entity IDs and negative system-reserved IDs. A more robust approach involves explicitly mapping team requests to their corresponding review records without relying on arithmetic inversion that could collide with reserved account identifiers. Additionally, input validation should ensure that the target of any modification operation strictly matches the intended scope, preventing cross-contamination between different types of entities such as teams and built-in service accounts. Regular audits of branch protection configurations and automated testing for edge cases involving negative or zero-valued IDs are essential to prevent similar logic flaws in other parts of the system.