Skip to main content

Gitea CVE-2026-58434

| EUVDEUVD-2026-58161 HIGH
Information Exposure (CWE-200)
2026-07-21 https://github.com/go-gitea/gitea GHSA-j2w3-9c3r-g83q
7.5
CVSS 3.1 · Vendor: https://github.com/go-gitea/gitea
Share

Severity by source

Vendor (https://github.com/go-gitea/gitea) PRIMARY
7.5 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
vuln.today AI
4.3 MEDIUM

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.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
4.0 AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
SUSE
HIGH
qualitative

Primary rating from Vendor (https://github.com/go-gitea/gitea).

CVSS VectorVendor: https://github.com/go-gitea/gitea

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
None
Availability
None

Lifecycle Timeline

6
Analysis Updated
Aug 14, 2026 - 18:46 vuln.today
v3 (cvss_changed)
Analysis Updated
Aug 14, 2026 - 18:45 vuln.today
v2 (cvss_changed)
Re-analysis Queued
Aug 14, 2026 - 18:22 vuln.today
cvss_changed
CVSS changed
Aug 14, 2026 - 18:22 NVD
7.5 (HIGH)
Source Code Evidence Fetched
Jul 21, 2026 - 21:19 vuln.today
Analysis Generated
Jul 21, 2026 - 21:19 vuln.today

DescriptionCVE.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:

http
GET /api/v1/user/starred

The same behavior was also observed on:

http
GET /api/v1/user/subscriptions

A reproducible scenario is:

  1. User alice creates a private repository.
  2. User bob is granted collaborator access.
  3. bob stars the repository.
  4. alice removes bob from the repository collaborators.
  5. Direct repository access by bob is denied.
  6. bob requests /api/v1/user/starred.
  7. 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
  1. Create a private repository:
text
alice/P
description = "INITIAL"
  1. Add bob as a collaborator with read access.
  2. As bob, star the repository:
http
PUT /api/v1/user/starred/alice/P

Response:

http
204 No Content
  1. Remove bob from the collaborator list.
  2. Update the repository description:
text
description = "AFTER-REVOKE"
  1. Verify that direct repository access is no longer allowed:
http
GET /api/v1/repos/alice/P

Response:

http
404 Not Found
  1. As bob, request the starred repository list:
http
GET /api/v1/user/starred

The response still contains the repository entry and reflects the updated description:

json
{
  "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.

Vendor StatusVendor

SUSE

Severity: Important
Product Status
SUSE Linux Enterprise Server 16.1 Affected
SUSE Linux Enterprise Server for SAP applications 16.1 Affected

Share

CVE-2026-58434 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy