CVE-2026-96589 in Gitea
Summary
by MITRE • 10/06/2026
When a private repository is transferred to a user who lacks access, Gitea grants that recipient temporary read access as a collaborator so they can review the repository. Rejecting or cancelling the transfer did not revoke this collaboration, so the named recipient kept persistent read access to the private repository, including its code, issues, pull requests and wiki, and could clone it. The repository owner was not notified. Transfer-granted access is now removed while collaborations that existed before the transfer are preserved.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability described involves a logic flaw in Gitea’s repository ownership transfer mechanism, specifically concerning how temporary collaborative permissions are handled during the transition of private repositories. When an owner initiates a transfer to another user who does not currently have access rights, the system automatically grants that recipient temporary read-only privileges as a collaborator. This design choice is intended to facilitate the review process by allowing the prospective new owner to inspect the repository’s contents before finalizing the transaction. However, the critical failure lies in the cleanup procedure when this transfer request is either rejected or cancelled by either party involved. Instead of revoking these temporary permissions upon cancellation, Gitea fails to remove them, resulting in a persistent state where the recipient retains full read access to all aspects of the private repository indefinitely.
This oversight creates a significant unauthorized information disclosure risk because it allows individuals who were never intended to have permanent access to maintain continuous visibility into sensitive codebases, issue trackers, pull requests, and wiki pages. The impact is compounded by the fact that the original repository owner receives no notification when this transfer request is cancelled or rejected. Consequently, the owner remains unaware that their private data has been exposed to an unauthorized party for an extended period. This lack of visibility prevents timely detection and remediation, potentially leading to prolonged exposure of proprietary source code, intellectual property, or sensitive project discussions depending on the repository's content and usage patterns.
From a technical perspective, this issue represents a failure in state management during workflow transitions, where temporary administrative actions are not properly cleaned up upon termination of the associated process. In terms of industry standards, this vulnerability aligns with CWE-284 Improper Access Control, as it involves granting access to users who should not have it and failing to revoke that access when conditions change. Furthermore, it relates to CWE-613 Insufficient Session Expiration because the temporary session or permission grant persists beyond its intended lifespan without automatic expiration or revocation mechanisms triggering upon cancellation of the transfer request. The ATT&CK framework categorizes this behavior under T1530 Data from Information Repositories, as an attacker could exploit this persistent access to exfiltrate code and other repository data that was not meant for their consumption.
To mitigate this vulnerability, Gitea has implemented a fix ensuring that any transfer-granted permissions are automatically removed when the transfer process is aborted or rejected. This ensures that only collaborations established prior to the transfer attempt remain active, preserving legitimate access while eliminating unauthorized persistent entry points. Administrators and users should ensure they are running a patched version of Gitea where this logic flaw has been corrected. Additionally, implementing regular audits of repository collaborators can help identify any lingering accounts that may have gained access through similar historical flaws before patches were applied. Organizations relying on private repositories for sensitive development work must verify their instance versions to prevent potential data leakage resulting from incomplete permission revocation during administrative workflows.