https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 13:31:03 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-352303 EUVD-2026-352303 https://cve.radiocsirt.org/vuln/euvd-2026-352303 https://cve.radiocsirt.org/vuln/fkie_cve-2026-58510 <p>GHSA-8fwc-qjw5-rvgp ClearRepoWatches fix not applied to API EditRepo path — sister code path retains stale watches on public-&gt;private</p> <p>GHSA-8fwc-qjw5-rvgp ClearRepoWatches fix not applied to API EditRepo path — sister code path retains stale watches on public-&gt;private</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-58510 https://cve.radiocsirt.org/vuln/ghsa-q423-49rw-g9mh <p><strong>Affected:</strong> Go: code.gitea.io/gitea</p> <p>## Summary</p> <p>GHSA-8fwc-qjw5-rvgp (&#34;Gitea may send release notification emails for private repositories to users whose access has been revoked&#34;, fix in PR #36319 / commit 8a98ac22) added `repo_model.ClearRepoWatches` as a defense for the state transition public→private. The cleanup was wired into `services/repository/repository.go::MakeRepoPrivate` only. The sister helper `services/repository/repository.go::updateRepository` — which is the function used by the API path `PATCH /api/v1/repos/{owner}/{repo}` — was not patched and still calls `ClearRepoStars` only.</p> <p>As a result, when a public repository is flipped to private via the REST API (rather than via the web Settings → Danger Zone UI), the watch records persist. Affected users can:</p> <p>- See the now-private repository in `GET /api/v1/user/subscriptions?private=true` along with its full `Repository` JSON (description, default branch, language, fork status, counts, mirror metadata, license list, etc.) — even though they have no access to the repository. - Have their stale watch records re-leak content through any future notification path that does not include the send-time `CheckRepoUnitUser` check that was added to `services/mailer/mail_release.go`. - Inflate the visible `NumWatches` counter on the repository.</p> <p>## Severity</p> <p>Medium — `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N`</p> <p>Same impact class as the original GHSA-8fwc-qjw5-rvgp (which was classified Medium). The send-time mail filter added in the same PR mitigates the rel…</p> <p><strong>Affected:</strong> Go: code.gitea.io/gitea</p> <p>## Summary</p> <p>GHSA-8fwc-qjw5-rvgp (&#34;Gitea may send release notification emails for private repositories to users whose access has been revoked&#34;, fix in PR #36319 / commit 8a98ac22) added `repo_model.ClearRepoWatches` as a defense for the state transition public→private. The cleanup was wired into `services/repository/repository.go::MakeRepoPrivate` only. The sister helper `services/repository/repository.go::updateRepository` — which is the function used by the API path `PATCH /api/v1/repos/{owner}/{repo}` — was not patched and still calls `ClearRepoStars` only.</p> <p>As a result, when a public repository is flipped to private via the REST API (rather than via the web Settings → Danger Zone UI), the watch records persist. Affected users can:</p> <p>- See the now-private repository in `GET /api/v1/user/subscriptions?private=true` along with its full `Repository` JSON (description, default branch, language, fork status, counts, mirror metadata, license list, etc.) — even though they have no access to the repository. - Have their stale watch records re-leak content through any future notification path that does not include the send-time `CheckRepoUnitUser` check that was added to `services/mailer/mail_release.go`. - Inflate the visible `NumWatches` counter on the repository.</p> <p>## Severity</p> <p>Medium — `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N`</p> <p>Same impact class as the original GHSA-8fwc-qjw5-rvgp (which was classified Medium). The send-time mail filter added in the same PR mitigates the rel…</p> https://cve.radiocsirt.org/vuln/ghsa-q423-49rw-g9mh 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