Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Endpoint requires a valid API token so PR:L, not PR:N; only metadata is disclosed so C:L, not C:H as the vendor assigned.
Primary rating from Vendor (https://github.com/go-gitea/gitea).
CVSS VectorVendor: https://github.com/go-gitea/gitea
Lifecycle Timeline
6DescriptionCVE.org
Summary
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.
Details
The issue affects the authenticated endpoint:
GET /api/v1/user/starredThe same behavior was also observed on:
GET /api/v1/user/subscriptionsA reproducible scenario is:
- User
alicecreates a private repository. - User
bobis granted collaborator access. bobstars the repository.aliceremovesbobfrom the repository collaborators.- Direct repository access by
bobis denied. bobrequests/api/v1/user/starred.- The repository is still present in the response together with repository metadata.
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.
PoC
PoC Link
https://anonymous.4open.science/r/Gitea_PoC-EC93/5_poc_starred_list
PoC Details
- Create a private repository:
alice/P
description = "INITIAL"- Add
bobas a collaborator with read access. - As
bob, star the repository:
PUT /api/v1/user/starred/alice/PResponse:
204 No Content- Remove
bobfrom the collaborator list. - Update the repository description:
description = "AFTER-REVOKE"- Verify that direct repository access is no longer allowed:
GET /api/v1/repos/alice/PResponse:
404 Not Found- As
bob, request the starred repository list:
GET /api/v1/user/starredThe 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.
Impact
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:
- Repository name (
full_name) - Repository description
- Repository visibility status (
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.
AnalysisAI
Private repository metadata leaks through the starred and watched repository API endpoints in Gitea versions prior to 1.27.0, allowing former collaborators to continue retrieving - and receiving live updates to - repository metadata after access revocation. Any authenticated user who starred a private Gitea repository while holding collaborator access can call GET /api/v1/user/starred with their existing API token and receive current repository metadata, including description changes made after their removal. A public proof-of-concept is available; the vulnerability is not in CISA KEV and EPSS indicates low observed exploitation activity at 0.15% (5th percentile).
Technical ContextAI
Gitea is a lightweight self-hosted open-source Git service written in Go (CPE: pkg:go/code.gitea.io/gitea). The root cause is CWE-200 (Exposure of Sensitive Information to Unauthorized Actor), arising from a missing access-control check in the query-builder layer. The StarredReposOptions and WatchedReposOptions structs in models/repo/user_repo.go previously lacked an Actor parameter, so when IncludePrivate was set the database query for starred or watched repositories omitted the AccessibleRepositoryCondition gate. The query thus filtered results only by star and watch records, not by current repository permissions, allowing stale star associations to return metadata the requester no longer has rights to view. The patch (PRs #38321 and #38390) introduces an Actor field to both option structs and applies AccessibleRepositoryCondition when private repositories are included, re-evaluating the requesting user's current access at query time rather than relying solely on historical star/watch records.
RemediationAI
Upgrade Gitea to version 1.27.0 or later, which incorporates the access-control fixes from pull requests #38321 (https://github.com/go-gitea/gitea/pull/38321) and #38390 (https://github.com/go-gitea/gitea/pull/38390) and their associated commits (362539b and 500a09e). The release is documented at https://blog.gitea.com/gitea-1.27.0-is-released/. If an immediate upgrade is not feasible, a compensating control is to block or restrict API access to the /api/v1/user/starred and /api/v1/user/subscriptions endpoints at the reverse-proxy or WAF layer for all non-owner users; note this will break legitimate starred and watched repository listing for all authenticated users, which may be operationally disruptive. No configuration toggle within Gitea itself disables the vulnerable behavior prior to the patch, so network-layer restriction is the only interim workaround.
Same weakness CWE-200 – Information Exposure
View allSame technique Information Disclosure
View allVendor StatusVendor
SUSE
Severity: Important| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-58161
GHSA-j2w3-9c3r-g83q