CVE-2026-96589: Gitea Auth Bypass Vulnerability

CVE-2026-96589 Overview

CVE-2026-96589 is a medium-severity access control vulnerability in Gitea, a self-hosted Git service. When a repository owner initiates a transfer of a private repository to a user who otherwise lacks access, Gitea grants that user temporary collaborator read access so they can review the repository before accepting. Rejecting or cancelling the transfer did not revoke this collaboration. The named recipient retained persistent read access to the private repository, including code, issues, pull requests, and the wiki, and could clone the repository. The repository owner received no notification that this access remained in place. The issue is tracked under [CWE-672] (Operation on a Resource after Expiration or Release).

Critical Impact
Unauthorized users retained read access to private repository contents after a transfer was rejected or cancelled, exposing source code and project metadata without owner awareness.

Affected Products

Gitea (self-hosted Git service) versions prior to 28.0.0
Private repositories involved in a transfer workflow
Transfer recipients that did not previously have collaborator access

Discovery Timeline

2026-10-06 - CVE-2026-96589 published to NVD
2026-10-07 - Last updated in NVD database

Technical Details for CVE-2026-96589

Vulnerability Analysis

Gitea's repository transfer workflow provisions a temporary collaboration record for the recipient. This record grants read access so the recipient can inspect the repository prior to accepting the transfer. The flaw lies in the lifecycle handling of that record. When the recipient rejects the transfer, or when the owner cancels it, Gitea does not remove the collaboration entry it created. The recipient keeps a valid collaborator relationship with the repository and continues to clone the code, read issues and pull requests, and view the wiki. The repository owner is not alerted, so the exposure can persist indefinitely without detection.

Root Cause

The root cause is improper cleanup of a transient authorization artifact. The transfer-initiation path and the transfer-termination path are not symmetric. The termination path omits the step that removes the collaboration row provisioned during initiation. The fix distinguishes between collaborations created by the transfer and collaborations that pre-existed. Transfer-granted access is removed on rejection or cancellation, while prior collaborations are preserved. The change is implemented in Gitea Pull Request #39042.

Attack Vector

Exploitation requires an authenticated user and an owner-initiated transfer. An attacker who is a legitimate Gitea user can wait to be named as a transfer recipient, or socially engineer a transfer, then reject it while retaining read access. The attack is network-reachable, requires low privileges, and needs no user interaction beyond the transfer workflow itself. Impact is limited to confidentiality of the targeted private repository.

No verified proof-of-concept code is published. The vulnerability is a logic flaw in the transfer state machine and does not require crafted payloads. See the GitHub Security Advisory GHSA-xfqq-h54g-92f8 for maintainer-supplied detail.

Detection Methods for CVE-2026-96589

Indicators of Compromise

Collaborator entries on private repositories that do not correspond to any owner-approved invitation.
Repository clone events, issue reads, or wiki views by users who were previously named as transfer recipients.
Transfer records marked rejected or cancelled where the recipient still appears on the repository collaborator list.

Detection Strategies

Query the Gitea database or API for collaborators on private repositories and correlate against the repository transfer history to find residual access.
Review audit logs for repo.transfer.start, repo.transfer.reject, and repo.transfer.cancel events and flag any case where the recipient subsequently performed repo.clone or read operations.
Compare collaborator lists before and after Gitea upgrade to 28.0.0; entries removed by the patch indicate prior unauthorized access.

Monitoring Recommendations

Enable Gitea access logs and forward Git protocol and API events to a central SIEM for correlation.
Alert on first-time clone activity from accounts that have never been explicitly added as collaborators by an owner.
Periodically reconcile repository ownership and collaborator state against an approved access-control baseline.

How to Mitigate CVE-2026-96589

Immediate Actions Required

Upgrade Gitea to version 28.0.0 or later, which removes transfer-granted collaborations on rejection or cancellation.
Audit all private repositories that have been subject to a transfer and remove any collaborator entries that were not approved by the owner.
Rotate any secrets, tokens, or credentials that may have been exposed in affected repository code, history, or issues.

Patch Information

The fix is included in Gitea 28.0.0. Refer to the Gitea 28.0.0 release announcement and the GitHub release notes for upgrade instructions. The underlying code change is in Pull Request #39042, which preserves pre-existing collaborations while revoking those created by the transfer workflow.

Workarounds

Until upgrade, avoid initiating transfers of private repositories to users who should not retain any access.
After any rejected or cancelled transfer on an unpatched instance, manually remove the recipient from the repository collaborator list.
Restrict transfer permissions through organization policy and require administrator approval for cross-owner repository transfers.

bash

# Verify Gitea version and list collaborators on a private repository
gitea --version
curl -H "Authorization: token $GITEA_TOKEN" \
  https://gitea.example.com/api/v1/repos/<owner>/<repo>/collaborators

# Remove an unauthorized collaborator left over from a rejected transfer
curl -X DELETE -H "Authorization: token $GITEA_TOKEN" \
  https://gitea.example.com/api/v1/repos/<owner>/<repo>/collaborators/<username>