CVE-2026-129341 in Gitea
Summary
by MITRE • 11/15/2026
The web endpoint that removes an attachment skipped the permission check when the request came from the user who had uploaded the attachment, and it was reachable with read access to issues or pull requests. A user who had uploaded a release asset could still delete it after losing write access to the repository. The endpoint now only deletes attachments that the user uploaded and that are not yet linked to an issue, comment or release.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/15/2026
The identified vulnerability represents a critical authorization flaw within the web application's attachment management subsystem, specifically affecting the endpoint responsible for removing file attachments from issues, pull requests, releases, comments, and other repository artifacts. This security deficiency stems from an incomplete access control check that fails to properly validate whether the requesting user retains sufficient privileges to perform deletion operations on resources they previously created but no longer own or have explicit permission to modify. The core technical flaw lies in the logic governing resource ownership versus current role-based permissions; while the system correctly restricts general modification rights based on current repository roles, it erroneously assumes that initial creation grants perpetual administrative control over the associated file metadata and storage objects, regardless of subsequent changes in user access levels or project membership status.
From a technical perspective, this vulnerability allows for unauthorized data manipulation through improper privilege escalation mechanisms inherent to object-level authorization failures. When a request is processed by the attachment removal endpoint, the application checks if the requester matches the uploader identity but neglects to verify current write permissions against the target resource's context. This oversight enables an attacker who previously held contributor or maintainer status and uploaded assets such as release binaries, documentation files, or issue attachments to retain deletion capabilities even after their access rights have been downgraded to read-only or revoked entirely. The operational impact of this flaw is significant, as it permits the destruction of critical project artifacts without proper audit trails or administrative oversight, potentially leading to data loss, disruption of continuous integration pipelines that rely on specific release assets, and degradation of trust in repository integrity for downstream consumers who depend on these files.
This vulnerability aligns with Common Weakness Enumeration category CWE-269, which addresses Improper Privilege Escalation, specifically manifesting as a broken access control scenario where users can perform actions beyond their assigned permissions due to flawed state management or ownership assumptions. In the context of the MITRE ATT&CK framework, this behavior corresponds to techniques involving resource hijacking and potential impact on availability through data destruction, falling under tactics related to Impact and Defense Evasion if an attacker uses deleted assets to obscure malicious activity or disrupt operational continuity. The lack of strict separation between creation-time ownership validation and runtime permission verification creates a window for abuse that undermines the principle of least privilege essential for secure software development environments.
To mitigate this risk, the application logic has been updated to enforce stricter authorization checks that decouple deletion rights from mere upload history. The revised implementation now restricts attachment removal exclusively to cases where the user uploaded the file and it remains unlinked to any persistent repository entity such as an issue, comment, or release artifact. This change ensures that once a resource becomes part of the broader project context with shared visibility and potential multi-user interaction, its lifecycle management reverts to standard permission models requiring explicit write access. Organizations relying on this platform should verify their current version status against vendor advisories and ensure that automated security testing pipelines include test cases for privilege escalation scenarios involving role transitions during asset lifetime cycles to prevent similar authorization bypasses in related modules.