https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 13 Oct 2026 08:28:04 +0000 https://cve.radiocsirt.org/vuln/cve-2026-58434 <p><strong>Affected:</strong> Gitea Open Source Git Server</p> <p>Private Repository Metadata Remains Accessible After Access Revocation</p> <p><strong>Affected:</strong> Gitea Open Source Git Server</p> <p>Private Repository Metadata Remains Accessible After Access Revocation</p> https://cve.radiocsirt.org/vuln/cve-2026-58434 https://cve.radiocsirt.org/vuln/ghsa-j2w3-9c3r-g83q <p><strong>Affected:</strong> Go: code.gitea.io/gitea</p> <p>### Summary</p> <p>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.</p> <p>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&#39;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.</p> <p>### Details</p> <p>The issue affects the authenticated endpoint:</p> <p>```http GET /api/v1/user/starred ```</p> <p>The same behavior was also observed on:</p> <p>```http GET /api/v1/user/subscriptions ```</p> <p>A reproducible scenario is:</p> <p>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.</p> <p>Additionally, if repository metadata is modified after access revocation, the updated values are returned by `/api/v1/user/starred`.</p> <p>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.</p> <p>### PoC</p> <p>#### PoC Link https://anonymous.4open.science/r/Gitea_PoC-EC93/5_poc_starred…</p> <p><strong>Affected:</strong> Go: code.gitea.io/gitea</p> <p>### Summary</p> <p>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.</p> <p>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&#39;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.</p> <p>### Details</p> <p>The issue affects the authenticated endpoint:</p> <p>```http GET /api/v1/user/starred ```</p> <p>The same behavior was also observed on:</p> <p>```http GET /api/v1/user/subscriptions ```</p> <p>A reproducible scenario is:</p> <p>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.</p> <p>Additionally, if repository metadata is modified after access revocation, the updated values are returned by `/api/v1/user/starred`.</p> <p>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.</p> <p>### PoC</p> <p>#### PoC Link https://anonymous.4open.science/r/Gitea_PoC-EC93/5_poc_starred…</p> https://cve.radiocsirt.org/vuln/ghsa-j2w3-9c3r-g83q