CVE-2026-58434

highpriority · track · 0OT risk · elevatedEPSS 0.005 · 40 %ileDEEURUUS
grimoire priorityP2 · Scheduled
Exploitable?
—
no known exploitation
Likely / severe?
0.47% (40th) EPSS
CVSS 7.5 · high
Is it mine?
9 products
Check your exposure
Who says so?
4 sources
enisa_euvd · fstec_bdu · osv · cert_bund

EPSS · scored 2026-10-27

Private Repository Metadata Remains Accessible After Access Revocation

01

cvss

Technical severity, 0–10. One row per scoring source.

7.5
010

base score 0–10 · higher = more severe · hover a vector to decode⚠ sources disagree · medium–high · 6.9–7.5

v3.17.5highAV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:Nsecondary · FSTEC (BDU) RU
v3.17.5highCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:Nsecondary · ENISA EU
v3.17.5highCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:Nsecondaryexploitability 3.9 · impact 3.6
v3.16.9mediumCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N/E:Usecondary · CVSS-BT (t0sche)
02

ssvc

A stakeholder decision — act, attend, or track — from exploitation and impact.

Exploitation: poc · Automatable: yes · Technical Impact: partialcoordinatorcisa_ssvcUS
03

weaknesses

The CWE weakness classes this flaw belongs to.

04

affected products (9)

Products and version ranges known to be affected.

05

advisories (3)

Vendor and ecosystem advisories describing this.

  • WID-SEC-W-2026-2304Gitea: Mehrere SchwachstellenDeutsch2026-07-13csaf · cert_bundDE

    Ein Angreifer kann mehrere Schwachstellen in Gitea ausnutzen, um beliebigen Programmcode auszuführen, erweiterte Berechtigungen zu erlangen, Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren, sensible Informationen offenzulegen, Sitzungen zu übernehmen oder wiederzuverwenden oder einen Denial-of-Service-Zustand auszulösen.

  • GHSA-j2w3-9c3r-g83qGitea: Private Repository Metadata Remains Accessible After Access Revocation2026-07-21ghsa · osvUS

    ### 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" ``` 2. Add `bob` as a collaborator with read access. 3. As `bob`, star the repository: ```http PUT /api/v1/user/starred/alice/P ``` Response: ```http 204 No Content ``` 4. Remove `bob` from the collaborator list. 5. Update the repository description: ```text description = "AFTER-REVOKE" ``` 6. Verify that direct repository access is no longer allowed: ```http GET /api/v1/repos/alice/P ``` Response: ```http 404 Not Found ``` 7. 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.

  • GO-2026-6062Gitea: Private Repository Metadata Remains Accessible After Access Revocation in gitea.dev2026-07-27vendor · osvUS

    Gitea: Private Repository Metadata Remains Accessible After Access Revocation in gitea.dev

06

also known as (6)

Other names and identifiers for this entity.

07

sources

Which sources assert this record, and when.

published 2026-08-13modified 2026-10-02
08

references (6)

External citations — patches, advisories, analysis.

scry

Attackers weaponise vulnerabilities like this against internet-exposed services. See what is exposed on your perimeter with a free passive scan.

Free scan