https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 01:07:03 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-352790 EUVD-2026-352790 https://cve.radiocsirt.org/vuln/euvd-2026-352790 https://cve.radiocsirt.org/vuln/fkie_cve-2026-58434 <p>Private Repository Metadata Remains Accessible After Access Revocation</p> <p>Private Repository Metadata Remains Accessible After Access Revocation</p> https://cve.radiocsirt.org/vuln/fkie_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 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2304 <p>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.</p> <p>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.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2304