CVE-2026-58434Low▾ SunlitGitea: Private Repository Metadata Remains Accessible After Access Revocation
▾ Sunlit zone — Low / medium · no exploitation signal
impact 13.8 · likelihood 0.1 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Aug 14.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via GHSA
0.1%
0.1% → 0.3%
A user who previously had access to a private repository can continue to obtain repository metadata through GET /api/v1/user/starred after their access to the repository has been revoked.
After a collaborator is removed from a private repository, direct access to the repository is correctly denied. However, the repository may still appear in the user's starred repository list, and the endpoint continues to return repository metadata. Changes made to that metadata after access revocation are also reflected in subsequent responses.
The issue affects the authenticated endpoint:
GET /api/v1/user/starred
The same behavior was also observed on:
GET /api/v1/user/subscriptions
A reproducible scenario is:
alice creates a private repository.bob is granted collaborator access.bob stars the repository.alice removes bob from the repository collaborators.bob is denied.bob requests /api/v1/user/starred.Additionally, if repository metadata is modified after access revocation, the updated values are returned by /api/v1/user/starred.
As a result, a user who no longer has permission to access the repository can continue to obtain repository metadata through the starred repository list.
https://anonymous.4open.science/r/Gitea_PoC-EC93/5_poc_starred_list
alice/P
description = "INITIAL"
Add bob as a collaborator with read access.
As bob, star the repository:
PUT /api/v1/user/starred/alice/P
Response:
204 No Content
Remove bob from the collaborator list.
Update the repository description:
description = "AFTER-REVOKE"
GET /api/v1/repos/alice/P
Response:
404 Not Found
bob, request the starred repository list:GET /api/v1/user/starred
The response still contains the repository entry and reflects the updated description:
{
"full_name": "alice/P",
"description": "AFTER-REVOKE",
"private": true
}
This demonstrates that repository metadata remains accessible through the starred repository list even after repository access has been revoked.
A user who previously had legitimate access to a private repository can continue to retrieve repository metadata after losing access to the repository.
The exposed information includes repository metadata returned by the endpoint, such as:
full_name)private)This issue does not expose repository contents, source code, issues, pull requests, secrets, or collaborator information.
The impact is limited to continued access to repository metadata after repository permissions have been revoked.
code.gitea.io/gitea < 1.27.0Upgrade to a patched release:
code.gitea.io/gitea 1.27.0Connected by shared product, vendor, weakness, or advisory.
CVE-2026-58432Medium· 5.9Gitea: draft release attachment disclosure via missing web authorization
CVE-2026-50105Medium· 4.3Gitea: RSS/Atom feed handlers bypass API-token scope & public-only confinement (incomplete fix of #37698)
CVE-2026-58510Medium· 4.3Gitea: GHSA-8fwc-qjw5-rvgp ClearRepoWatches fix not applied to API EditRepo path — sister code path retains stale watches on public->private
CVE-2026-57897Medium· 6.5Gitea: Cross-Repo Information Disclosure via Org-Level Actions Run/Job APIs
CVE-2026-58511Low· 2.7Gitea: Webhook Authorization Header Returned in Plaintext via API
CVE-2026-58425Medium· 4.3Gitea: OAuth token introspection returns metadata of tokens issued to other clients (RFC 7662 section 4 violation)